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本 书 提供 了 关于 软件 应 用 建 模 和 设计 的 知识 。 从 UML 中 的 用 例 到 软件 体系 结构 ， 本 书展 示 了 如 何在 解决 
实际 问题 的 过 程 中 应 用 COMET ( 协作 式 对 象 建 模 和 体系 结构 设计 方法 ) 这 种 基于 UML 的 建 模 和 设计 方法 ， 
介绍 了 针对 各 种 体系 结构 的 模式 ， 包 括 客户 端 /服务 器 和 基于 构件 的 软件 体系 结构 中 的 客户 端 / 服 务 模式 ， 面 
向 服务 的 体系 结构 中 的 代理 、 发 现 和 事务 模式 ， 实 时 软件 体系 结构 中 的 实时 控制 模式 ， 软 件 产品 线 体系 结构 
中 的 分 层 模 式 s- 此 外 二 还 介绍 子 软件 质量 属性 :包括 可 维护 性 可 修改 性 可 测试 性 可 追踪 性 可 伸缩 
性 、 可 复 用 性 、 性 能 、 可 用 性 和 安全 性 。 

四 个 完整 的 案例 研究 阐明 了 针对 不 同 软件 体系 结构 的 设计 问题 : 针对 客户 端 /服务 器 体系 结构 的 银行 系 
统 、 针 对 面向 服务 的 体系 结构 的 在 线 购 物 系 统 、 针 对 基于 构件 的 软件 体系 结构 的 应 急 监 控 系统 、 针 对 实时 软 
件 体系 结构 的 自动 引导 车 辆 系统 。 
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文艺 复兴 以 降 ， 源 远 流 长 的 科学 精神 和 逐步 形成 的 学 术 规范 ， 使 西方 国家 在 自然 科学 的 
各 个 领域 取得 了 垄断 性 的 优势 ; 也 正 是 这 样 的 传统 ， 使 美国 在 信息 技术 发 展 的 六 十 多 年 间 名 
家 辈出 、 独 领 风 骚 。 在 商业 化 的 进程 中 ， 美 国 的 产业 界 与 教育 界 越 来 越 紧密 地 结合 ， 计 算 机 
学 科 中 的 许多 泰山 北斗 同时 身 处 科研 和 教学 的 最 前 线 ， 由 此 而 产生 的 经 典 科学 著作 ， 不 仅 壁 
划 了 研究 的 范畴 ， 还 揭示 了 学 术 的 源 变 ， 既 遵循 学 术 规 范 ， 又 自 有 学 者 个 性 ， 其 价值 并 不 会 
因 年 月 的 流逝 而 减退 。 

近年 ， 在 全 球 信息 化 大 潮 的 推动 下 ,我 国 的 计算 机 产业 发 展 迅猛 ， 对 专业 人 才 的 需求 日 
益 迫 切 。 这 对 计算 机 教育 界 和 出 版 界 都 既是 机 遇 ， 也 是 挑战 ;而 专业 教材 的 建设 在 教育 战略 
上 显得 举足轻重 。 在 我 国信 息 技 术 发 展 时 间 较 短 的 现状 下 ， 美 国 等 发 达 国 家 在 其 计算 机 科学 
发 展 的 几 十 年 间 积淀 和 发 展 的 经 典 教材 仍 有 许多 值得 借鉴 之 处 。 因 此 ， 引 进 一 批 国外 优秀 计 
算 机 教材 将 对 我 国 计 算 机 教育 事业 的 发 展 起 到 积极 的 推动 作用 ， 也 是 与 世界 接轨 、 建 设 真正 
的 世界 一 流 大 学 的 必由之路 。 

机 械 工 业 出 版 社 华 章 公 司 较 早 意识 到 “出 版 要 为 教育 服务 "。 自 1998 年 开始 ， 我 们 
就 将 工作 重点 放 在 了 六 选 、 移 译 国外 优秀 教材 上 。 经 过 多 年 的 不 懈 努 力 ， 我 们 与 Pearson, 
McGraw-Hill, Elsevier, MIT, John Wiley & Sons, Cengage 等 世界 著名 出 版 公司 建立 了 良 
好 的 合作 关系 ,从 他 们 现 有 的 数 百 种 教材 中 甄选 出 Andrew S. Tanenbaum, Bjarne Stroustrup, 
Brain W. Kernighan, Dennis Ritchie, Jim Gray, Afred V. Aho, John E. Hopcroft, Jeffrey D. 
Ullman, Abraham Silberschatz, William Stallings, Donald E. Knuth, John L. Hennessy, Larry L. 
Peterson 等 大 师 名 家 的 一 批 经典 作 品 ， 以 “计算 机 科学 丛书 ”为 总 称 出 版 ， 供 读者 学 习 、 研 
究 及 珍藏 。 大 理 石 纹理 的 封面 ， 也 正体 现 了 这 套 从 书 的 品位 和 格调 。 

“计算 机 科学 丛书 ”的 出 版 工作 得 到 了 国内 外 学 者 的 易 力 圳 助 ， 国 内 的 专家 不 仅 提 供 了 
中 肯 的 选 题 指 导 ， 还 不 酬劳 苦 地 担任 了 翻译 和 审 校 的 工作 ; 而 原 书 的 作者 也 相当 关注 其 作品 
在 中 国 的 传播 ， 有 的 还 专程 为 其 书 的 中 译本 作 序 。 迄 今 ,“ 计 算 机 科学 丛书 ”已 经 出 版 了 近 两 
百 个 品种 ， 这 些 书籍 在 读者 中 树立 了 良好 的 口碑 ， 并 被 许多 高 校 采 用 为 正式 教材 和 参考 书籍 。 
其 影印 版 “经 典 原版 书库 ”作为 姊妹 篇 也 被 越 来 越 多 实施 双语 教学 的 学 校 所 采用 。 

权威 的 作者 、 经 典 的 教材 、 一 流 的 译 者 、 严 格 的 审 校 、 精 细 的 编辑 ， 这 些 因素 使 我 们 的 
图 书 有 了 质量 的 保证 。 随 着 计算 机 科学 与 技术 专业 学 科 建 设 的 不 断 完善 和 教材 改革 的 逐渐 深 
化 ,教育 界 对 国外 计算 机 教材 的 需求 和 应 用 都 将 步 人 一 个 新 的 阶段 ， 我 们 的 目标 是 尽善尽美 ， 
而 反馈 的 意见 正 是 我 们 达到 这 一 终极 目标 的 重要 帮助 。 华 章 公司 欢迎 老师 和 读者 对 我 们 的 工 
作 提 出 建议 或 给 予 指正 ， 我 们 的 联系 方法 如 下 : 


华章 网 站 : www.hzbook.com 
电子 邮件 : hzjsj@hzbook.com 


联系 电话 : (010) 88379604 


HZ BOOKS 


联系 地 址 : 北京 市 西城 区 百 万 庄 南 街 1 号 华章 教育 
邮政 编码 : 100037 华章 科技 图 书 出 版 中 心 
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软件 开发 的 主要 困难 在 于 概念 化 层次 上 的 问题 理解 和 方案 规划 ， 主 要 包括 需求 理解 、 分 
析 和 软件 设计 。 其 中 ， 软 件 体系 结构 设计 是 一 项 最 具 挑 战 性 的 任务 。 一 个 高 质量 的 软件 体系 
结构 应 当 完 整 、 准 确 地 实现 特定 软件 系统 所 要 求 的 各 项 功能 需求 ， 同 时 实现 性 能 、 可 用 性 、 
可 伸缩 性 、 可 维护 性 等 软件 质量 属性 。 为 此 ,设计 人 员 需 要 全 面 、 准 确 地 理解 软件 需求 和 软 
件 质量 属性 ， 掌 握 各 种 常见 的 软件 体系 结构 模式 并 具有 在 特定 问题 环境 中 综合 应 用 多 种 模式 
的 能 力 。 此 外 ， 为 了 准确 、 规 范 地 描述 需求 模型 、 分 析 模 型 、 体 系 结构 模式 以 及 特定 的 体系 
结构 设计 模型 ， 统 一 、 规 范 的 可 视 化 建 模 语言 及 相应 的 建 模 指 导 也 是 必 不 可 少 的 。 

本 书面 向 软件 体系 结构 设计 ， 以 统一 建 模 语言 (UML ) 为 基础 ， 从 基于 用 例 的 需求 建 
模 、 基 于 类 图 的 静态 建 模 、 基 于 对 象 交 互 分 析 的 动态 建 模 、 状 态 机 建 模 等 基本 的 需求 和 分 析 
建 模 手 段 开 始 ， 逐 步 介 绍 了 多 种 软件 体系 结构 模式 以 及 基于 模式 的 软件 体系 结构 设计 方法 。 
这 些 体系 结构 模式 覆盖 了 当前 最 为 流行 的 多 种 软件 体系 结构 类 型 ， 包 括 面向 对 象 的 软件 体系 
结构 、 客 户 端 /服务 器 软件 体系 结构 、 面 向 服务 的 软件 体系 结构 、 基 于 构件 的 软件 体系 结构 、 
并 发 和 实时 软件 体系 结构 以 及 软件 产品 线 体 系 结构 。 本 书 还 提供 了 四 个 详细 的 案例 研究 以 及 
一 系列 模型 实例 ， 所 有 例子 都 使 用 UML 2 表示 法 进行 描述 。 本 书 不 仅 适 用 于 高 年 级 本 科 生 及 
研究 生 软 件 分 析 与 设计 相关 课程 教学 ， 而 且 还 可 以 作为 软件 开发 和 管理 相关 领域 专业 人 员 学 
习 、 应 用 软件 分 析 与 设计 方法 和 建 模 规范 的 参考 。 

彭 奢 、 吴 毅 坚 、 赵 文 簿 主要 组 织 并 参加 了 本 书 的 翻译 和 审 校 工作 。 其 中 ， 芯 伟 负 责 第 1 
章 、 第 12 ~ 19 章 、 第 21 ~ 24 章 、 附 录 及 索引 的 翻译 工作 ， 吴 妆 坚 负责 第 2 ~ 11 章 、 第 20 
BRAM MELE, БОНИ Taek. BMA LPM BEAK. Ka, % 
文 亿 、 赵 欣 等 。 

由 于 本 书 内 容 丰富 、 才 盖 面 广 ， 同 时 译 者 水 平 有 限 ， 译 文中 难免 有 玻 漏 或 错误 ， 奶 请 各 
位 读者 批评 指正 。 
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概述 


本 书 介 绍 了 一 种 用 例 驱动 、 基 于 UML 的 软件 体系 结构 建 模 和 设计 方法 ,包括 面向 对 象 
的 软件 体系 结构 、 客 户 端 /服务 器 软件 体系 结构 、 面 向 服务 的 体系 结构 、 基 于 构件 的 软件 体 
系 结构 、 并 发 和 实时 软件 体系 结构 ， 以 及 软件 产品 线 体系 结构 。 本 书 为 软件 体系 结构 设计 提 
供 了 一 套 统一 的 方法 ， 同 时 针对 每 种 类 型 的 软件 体系 结构 进行 了 特殊 考虑 。 此 外 ， 本 书 还 包 
含 了 四 个 案例 研究 : 一 个 客户 端 /服务 器 银行 系统 、 一 个 面向 服务 的 体系 结构 的 在 线 购物 系 
统 、 一 个 基于 构件 的 分 布 式 应 急 监 控 系 统 和 一 个 实时 自动 引导 车 辆 系统 。 

本 书 介 绍 了 一 种 基于 UML 的 软件 建 模 和 设计 方法 一 一 COMET (Collaborative Object 
Modeling and Architectural Design Method )。COMET 是 一 种 高 度 迭 代 的 面向 对 象 的 软件 开发 
方法 ,覆盖 了 面向 对 和 象 开发 生存 周期 的 需求 、 分 析 和 设计 建 模 阶 段 。 

本 书 针对 希望 使 用 一 种 系统 化 的 基于 UML 的 方法 ( 从 基于 用 例 的 需求 建 模 开 始 ， 通 过 
静态 和 动态 建 模 ， 直 至 基于 体系 结构 设计 模式 的 软件 设计 ) 来 设计 软件 体系 结构 的 读者 。 


本 书 内 容 


目前 市 场 上 有 很 多 介绍 面向 对 象 分 析 和 设计 概念 及 方法 的 书 。 本 书 针对 设计 软件 体系 结 
构 的 特定 需要 ， 介 绍 了 基于 UML 的 软件 体系 结构 设计 ， 由 基于 用 例 的 需求 建 模 、 基 于 类 图 的 
静态 建 模 、 基 于 对 象 交 互 分 析 的 动态 建 模 和 状态 机 建 模 开始 ， 直 至 基于 体系 结构 设计 模式 的 软 
件 设计 。 书 中 所 有 的 例子 都 使 用 UML 2 表示 法 进行 描述 。 有 具体 而 言 ， 本 书包 括 以 下 内 容 : 
ө 全 面 介 绍 了 应 用 基于 UML 的 面向 对 象 概念 进行 需求 建 模 、 分 析 建 模 和 设计 建 模 。 需 
求 建 模 包括 用 例 建 模 ， 以 描述 功能 性 需求 ， 同 时 通过 扩展 的 方式 来 描述 非 功能 性 需 
求 。 分 析 建 模 包 括 静 态 建 模 和 动态 建 模 ( 交互 建 模 和 状态 机 建 模 )。 设 计 建 模 涉 及 重 
要 的 体系 结构 问题 ， 包 括 一 种 将 基于 用 例 的 交互 图 集成 到 初始 软件 体系 结构 以 及 应 用 
体系 结构 和 设计 模式 来 设计 软件 体系 结构 的 系统 化 的 方法 。 
о 提供 了 一 种 通用 的 需求 和 分 析 建 模 方法 ， 并 且 分 析 了 设计 不 同类 型 的 软件 体系 结构 所 
面 对 的 特定 问题 ( 每 种 类 型 的 软件 体系 结构 对 应 一 章 )， 包 括 面向 对 象 的 软件 系统 、 
客户 端 /服务 器 系统 、 面 向 服务 的 系统 、 基 于 构件 的 系统 、 实 时 系统 和 软件 产品 线 。 
。 介绍 了 如 何 通过 首先 考虑 与 相应 的 软件 体系 结构 类 型 相关 的 模式 来 设计 软件 体系 结 
№, 包括 : 针对 客户 端 /服务 器 以 及 基于 构件 的 软件 体系 结构 的 客户 端 /服务 模式 ; 
针对 面向 服务 的 体系 结构 的 代理 、 发 现 和 事务 模式 ; 针对 实时 软件 体系 结构 的 实时 控 
制 模式 ; 针对 软件 产品 线 体 系 结构 的 分 层 模式 。 
© 介绍 了 对 软件 产品 质量 有 重要 影响 的 软件 质量 属性 。 其 中 很 多 属性 都 可 以 在 软件 体系 
结构 设计 时 进行 考虑 和 评价 。 所 涉及 的 软件 质量 属性 包括 可 维护 性 、 可 修改 性 、 可 测 
试 性 、 可 追踪 性 、 可 伸缩 性 、 可 复 用 性 、 性 能 、 可 用 性 和 安全 性 。 


° 介绍 了 四 个 详细 的 案例 研究 。 这 些 案例 研究 按照 软件 体系 结构 类 型 进行 组 织 ， 包 括 针 
对 客户 端 /服务 器 体系 结构 的 银行 系统 、 针 对 面向 服务 的 体系 结构 的 在 线 购 物 系 统 、 
针对 基于 构件 的 软件 体系 结构 的 应 急 监 控 系 统 ， 以 及 针对 实时 软件 体系 结构 的 自动 引 
导 车 辆 系统 。 

© 本 书 最 后 提供 了 软件 体系 结构 模式 分 类 、 针 对 基于 本 书 进 行 学 术 性 课程 和 工业 课程 
教学 的 教学 建议 以 及 术语 表 、 参 考 文献 、 索 引 。 此 外 ， 本 书 的 大 多 数 章节 后 都 包含 
相应 的 练习 。 


目标 读者 


本 书 的 目标 读者 包括 学 术 界 以 及 计算 机 相关 专业 的 从 业 人 员 。 学 术 界 的 目标 读者 包括 计 
算 机 科学 及 软件 工程 专业 的 高 年 级 本 科 生 、 研 究 生 以 及 本 领域 的 研究 者 。 相 关 从 业 人 员 包 括 
参与 大 规模 工业 和 政府 软件 系统 的 分 析 、 设 计 和 开发 的 分 析 师 、 软 件 架 构 师 、 软 件 设计 人 员 、 
程序 员 、 项 目 经 理 、 技 术 经 理 、 程 序 经 理 和 质量 保障 专家 。 


阅读 本 书 的 方式 


本 书 可 以 通过 多 种 不 同 的 方式 进行 阅读 。 可 以 按 章节 顺序 进行 阅读 : 第 1 章 至 第 4 章 提 
供 了 介绍 性 的 概念 ; 第 5 章 对 COMET/UML 软件 建 模 和 设计 方法 进行 了 概述 ; 第 6 章 至 第 
20 章 对 软件 建 模 和 设计 进行 了 深入 介绍 ; 第 21 章 至 第 24 章 提 供 了 详细 的 案例 研究 。 

除 此 之 外 ， 有 些 读者 可 能 希望 跳 过 某 些 章节 ， 这 取决 于 读者 对 相关 内 容 的 熟悉 程度 。 第 1 
章 至 第 4 章 是 介绍 性 的 内 容 ， 有 经 验 的 读者 可 以 跳 过 。 熟 悉 软 件 设 计 思想 的 读者 可 以 跳 过 第 4 
章 。 对 软件 建 模 和 设计 特别 感 兴趣 的 读者 可 以 直接 从 第 5 章 开始 阅读 关于 COMET/UML 的 介 
绍 。 不 熟悉 UML 或 者 对 UML 2 的 变化 感 兴趣 的 读者 可 以 阅读 第 2 章 以 及 第 5 章 至 第 20 章 。 

有 经 验 的 软件 设计 者 还 可 以 将 本 书 作 为 参考 书 ， 将 各 章 作为 项 目 到 达 需 求 、 分 析 或 设计 
过 程 中 特定 阶段 时 的 参考 。 每 一 章 的 内 容 都 相对 独立 。 例 如 ， 可 以 通过 第 6 章 了 解 用 例 ， 通 
过 第 7 章 了 解 静 态 建 模 ， 通 过 第 9 章 了 解 动态 交互 建 模 。 第 10 章 可 以 作为 设计 状态 机 的 参 
考 ; 第 12 章 和 附录 A 可 以 作为 软件 体系 结构 模式 的 参考 ; 第 14 章 可 以 作为 面向 对 象 软件 
体系 结构 的 参考 ; 第 15 章 可 以 作为 基于 静态 模型 设计 关系 数据 库 的 参考 。 可 以 通过 第 16 章 
了 解 面向 服务 的 体系 结构 ; 通过 第 17 章 了 解 基于 构件 的 分 布 式 软件 设计 ; 通过 第 18 章 了 解 
实时 设计 ; 通过 第 19 章 了 解 软件 产品 线 设 计 。 也 可 以 通过 阅读 案例 研究 来 加 强 对 如 何 使 用 
COMET/UML 方法 的 理解 ， 因 为 每 个 案例 研究 都 对 实际 应 用 的 设计 中 需求 、 分 析 和 设计 建 模 
过 程 所 做 出 的 各 种 决策 进行 了 解释 。 


Hassan Gomaa 
邮件 地 址 : hgomaa@gmu.edu 
个 人 网 站 : http://mason.gmu.edu/~hgomaa 


| 本 书 导 读 


Software Modeling & Design: UML, Use Cases, Patterns, & Software Architectures 


第 一 部 分 : 概览 


第 1 章 : 引言 

本 章 对 软件 建 模 和 设计 进行 了 简要 介绍 ， 讨 论 了 一 些 软件 设计 问题 ， 介 绍 了 软件 体系 结 
构 ， 此 外 还 概述 了 基于 UML 的 面向 对 象 分 析 和 设计 。 
第 2 章 : UML 表示 法 概述 


本 章 介 绍 了 UML 表示 法 ， 包 括 用 例 图 、 类 图 、 交 互 图 、 状 态 图 、 包 图 、 并 发 通信 图 和 
部 署 图 。 本 章 还 介绍 了 UML 扩展 机 制 以 及 UML 逐渐 标准 化 的 发 展 过 程 。 


第 3 章 : 软件 生存 周期 模型 和 过 程 


本 章 介绍 了 用 于 开发 软件 的 软件 生存 周期 模型 ， 包 括 瀑布 模型 、 原 型 过 程 、 和 迭代 过 程 、 
螺旋 模型 和 统一 过 程 。 本 章 还 对 这 些 过 程 和 模型 进行 了 比较 。 


第 4 章 : 软件 设计 和 体系 结构 概念 


本 章 对 一 些 关 键 的 软件 设计 概念 进行 了 介绍 和 讨论 ， 包 括 类 、 对 象 、 信 息 隐 藏 和 继承 等 
面向 对 象 的 设计 概念 ， 以 及 使 用 并 发 对 象 的 并 发 处 理 。 此 外 ,本章 还 介绍 了 软件 体系 结构 和 
构件 、 软 件 设计 模式 以 及 软件 质量 属性 。 


第 5 章 : 软件 建 模 和 设计 方法 概览 


本 章 对 软件 建 模 和 设计 方法 进行 了 概述 ， 包 括 需 求 建 模 、 分 析 建 模 和 设计 建 模 。 此 外 ， 
本 章 还 对 本 书 中 所 涉及 的 各 种 不 同类 型 的 软件 体系 结构 进行 了 概述 。 


第 二 部 分 : 软件 建 模 


第 6 章 : 用 例 建 模 


本 章 首先 对 需求 分 析 和 需求 规约 进行 了 概述 ， 然 后 介绍 了 用 于 需求 开发 的 用 例 建 模 方法 ， 
接 下 来 介绍 了 一 种 用 例 开发 方法 。 本 章 涉及 用 例 、 参 与 者 、 识 别 用 例 、 描 述 用例 以 及 用 例 关 系 。 
本 章 还 介绍 了 用 于 单个 用 例 细 化 建 模 的 活动 图 。 此 外 ， 用 例 还 被 扩展 用 于 描述 非 功能 性 需求 。 


第 7 章 : 静态 建 模 


本 章 介绍 了 静态 建 模 的 相关 概念 ， 包 括 关联 、 整 体 / 部 分 关系 〈 组 合 和 聚合 ) 以 及 泛 化 / 
特 化 关系 。 此 外 ， 本 章 还 介绍 了 一 些 特 殊 问题 ， 包 括 系统 边界 的 建 模 、 信 息 密集 的 实体 类 建 模 。 


第 8 章 : 对 象 和 类 组 织 
本 章 介 绍 了 应 用 类 的 分 类 ， 即 类 在 应 用 中 所 扮演 的 不 同 角色 。 主 要 的 分 类 包括 边界 对 象 、 
实体 对 象 、 控 制 对 象 和 应 用 逻辑 对 象 。 本 章 还 介绍 了 各 种 对 象 相应 的 行为 模式 。 


УШ 


Жо: 动态 交互 建 模 

本 章 介 绍 了 动态 交互 建 模 概 念 。 针 对 每 个 用 例 所 开发 的 交互 ( 顺序 或 通信 ) 图 包括 主场 
景 和 可 替换 场景 。 本 章 还 介绍 了 如 何 从 用 例 开始 开发 交互 模型 。 
第 10 章 : 有 限 状 态 机 


本 章 介绍 了 有 限 状 态 机 建 模 的 概念 。 具 体 而 言 ， 一 个 状态 相关 的 控制 类 需要 使 用 有 限 状 
态 机 建 模 并 描述 为 状态 图 。 本 章 还 介绍 了 事件 、 状 态 、 条 件 、 动 作 、 进 入 和 退出 动作 、 复 合 
状态 、 顺 序 和 正 交 状态 。 


第 11 章 : 状态 相关 的 动态 交互 建 模 


本 章 介 绍 了 状态 相关 的 对 象 交 互 的 动态 交互 建 模 ， 包 括 状 态 机 和 交互 图 如 何 相 互 关联 以 
及 二 者 如 何 保持 一 致 。 


第 三 部 分 : 软件 体系 结构 设计 


第 12 章 : 软件 体系 结构 概览 

本 章 介绍 了 软件 体系 结构 的 概念 ， 包 括 软 件 体系 结构 的 多 视图 、 软 件 体 系 结构 模式 ( 结 
构 模 式 和 通信 模式 )， 提 供 了 一 种 软件 体系 结构 模式 的 描述 模板 ， 此 外 还 对 接口 设计 进行 了 介 
绍 和 讨论 。 
第 13 章 : 软件 子 系统 体系 结构 设计 

本 章 介绍 了 软件 体系 结构 设计 的 各 种 问题 ， 包 括 从 分 析 到 体系 结构 设计 的 转换 、 子 系统 
设计 中 的 关注 点 分 离 、 子 系统 组 织 准 则 ， 以 及 子 系统 消息 通信 接口 的 设计 。 
第 14 章 : 设计 面向 对 象 的 软件 体系 结构 

本 章 介绍 了 顺序 性 软件 体系 结构 的 面向 对 象 设 计 ， 特 别 是 使 用 信息 隐藏 、 类 和 继承 等 思 
想 的 设计 。 在 类 接口 设计 中 ， 类 的 设计 者 需要 决定 哪些 信息 应 该 隐藏 而 哪些 信息 应 该 通过 类 
接口 ( 由 类 所 提供 的 操作 组 成 ) 暴露 出 来 。 本 章 讨 论 了 契约 式 设 计 和 顺序 性 类 设计 ， 包 括 数 
据 抽象 类 、 状 态 机 类 、 图 形 用 户 界 面 类 和 业务 逻辑 类 的 设计 ， 此 外 还 讨论 了 类 的 详细 设计 。 
第 15 =: 设计 客户 端 / 服务 器 软件 体系 结构 

本 章 介 绍 了 客户 端 和 服务 器 的 设计 ， 并 对 客户 端 / 服务 模式 ( 结构 以 及 行为 )、 顺 序 性 和 
并 发 服务 、 从 静态 模型 到 关系 数据 库 的 映射 ( 包括 数据 库 包 装 器 的 设计 以 及 逻辑 关系 数据 库 
的 设计 ) 进行 了 讨论 。 
第 16 =: 设计 面向 服务 的 体系 结构 

本 章 介绍 了 面向 服务 的 体系 结构 的 特点 ， 讨 论 了 Web 服务 和 服务 模式 ， 包 括 注册 、 代 理 
和 发 现 模式 ， 然 后 介绍 了 事务 模式 和 事务 设计 ， 包 括 原 子 事务 、 两 阶段 提交 协议 、 复 合 事务 
和 长 事务 。 本 章 还 介绍 了 如 何 设计 可 复 用 的 服务 、 如 何 基于 服务 复 用 构建 应 用 、 服 务 协 调 。 
第 17 章 : 设计 基于 构件 的 软件 体系 结构 

本 章 介 绍 了 基于 构件 的 分 布 式 软件 体系 结构 设计 ， 包 括 构件 接口 〈 供给 接口 及 请 求 接口 ) 
设计 。 本 章 还 讨论 了 基于 构件 的 软件 体系 结构 如 何 使 用 结构 化 类 和 UML 2 中 引入 的 复合 结构 
图 表示 法 进行 描述 ， 该 表示 法 可 以 描述 构件 、 端 口 、 连 接 器 、 供 给 和 请 求 接口 。 


第 18 章 : 设计 并 发 和 实时 软件 体系 结构 

本 章 分 析 了 区 入 式 实时 系统 的 特点 ， 讨 论 了 并 发 与 控制 、 实 时 系统 的 控制 模式 、 并 发 任 
务 组 织 ( 包括 事件 驱动 的 任务 、 周 期 性 任务 和 按 需 驱动 的 任务 ) 以 及 任务 接口 的 设计 (包括 
消息 通信 、 事 件 同步 和 通过 被 动 对 象 的 通信 )。 
第 19: 设计 软件 产品 线 体系 结构 


本 章 介绍 了 软件 产品 线 的 特点 一 一 面向 产品 族 进行 共性 和 可 变性 建 模 ， 讨 论 了 特征 建 模 、 
可 变性 建 模 、 软 件 产品 线 体系 结构 和 应 用 工程 。 本 章 还 介绍 了 用 例 、 静 态 和 动态 模型 、 软 件 
体系 结构 中 的 可 变性 建 模 。 


第 20 章 : 软件 质量 属性 


本 章 介绍 了 软件 质量 属性 以 及 如 何 使 用 软件 质量 属性 评价 软件 体系 结构 的 质量 。 软 件 质 
量 属性 包括 可 维护 性 、 可 修改 性 、 可 追踪 性 、 可 用 性 、 可 复 用 性 、 可 测试 性 、 性 能 和 安全 性 。 
本 章 还 讨论 了 体系 结构 设计 方法 如 何 支 持 软件 质量 属性 。 


第 四 部 分 : 案例 研究 


每 个 案例 研究 都 详细 描述 了 如 何 应 用 此 前 所 介绍 的 概念 和 方法 设计 各 种 不 同 的 软件 体系 
结构 : 客户 端 /服务 器 软件 体系 结构 、 面 向 服务 的 体系 结构 、 基 于 构件 的 软件 体系 结构 ， 以 
及 实时 软件 体系 结构 。 每 个 案例 研究 都 对 建 模 和 设计 决策 的 原理 进行 了 讨论 。 

第 21 章 : 客户 端 / 服 务 器 软件 体系 结构 案例 研究 : 银行 系统 


本 章 介绍 了 如 何 应 用 软件 建 模 和 设计 方法 来 设计 一 个 由 一 个 银行 服务 器 和 多 个 АТМ # 
户 端 组 成 的 客户 端 /服务 器 系统 一 一 银行 系统 。ATM 客户 端的 设计 同时 也 是 并 发 软件 设计 的 
例子 。 银 行 服务 的 设计 是 顺序 性 面向 对 象 设 计 的 例子 。 


第 22 章 : 面向 服务 的 体系 结构 案例 研究 : 在 线 购物 系统 


本 章 介绍 了 如 何 应 用 软件 建 模 和 设计 方法 来 设计 一 人 
购物 系统 ， 其 中 包 合 多 个 由 多 个 客户 端 调用 的 服务 并 且 需 要 服务 代理 、 服 务 发 现 和 服务 协调 。 


第 23 章 : 基于 构件 的 软件 体系 结构 案例 研究 : 应 急 监 控 系 统 


本 章 介绍 了 如 何 应 用 软件 建 模 和 设计 方法 来 设计 一 个 基于 构件 的 软件 体系 结构 
监控 系统 ， 其 中 软件 构件 可 以 在 部 署 时 被 分 配 到 硬件 配置 上 。 


第 24 章 : 实时 软件 体系 结构 案例 研究 : 自动 引导 车 辆 系统 


本 章 介绍 了 如 何 应 用 软件 建 模 和 设计 方法 来 设计 一 个 实时 自动 引导 车 辆 系统 ( 由 多 个 并 
发 任务 组 成 )。 该 系统 是 一 个 工厂 自动 化 系统 之 系统 (system of system ) 的 一 部 分 。 


附录 A: 软件 体系 结构 模式 分 类 


为 便于 参照 ， 本 附录 按照 通用 模板 对 本 书 中 所 用 到 的 软件 体系 结构 的 结构 模式 、 通 信 模 
式 和 事务 模式 进行 了 描述 。 


附录 B: 教学 考虑 
本 附录 描述 了 基于 本 书 进行 学 术 性 教学 和 工业 课程 教学 的 方法 。 
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1.1 软件 建 模 


建 模 在 各 行 各 业 中 都 得 到 了 广泛 应 用 ， 其 至 可 以 追溯 到 早期 文明 ,例如 古代 埃及 、 罗 马 
和 希腊 ， 那 时 建 模 被 用 于 提供 艺术 和 建 
筑 学 中 的 小 规模 规划 ( 图 1-1 )。 建 模 在 
科学 和 工程 中 广泛 用 于 在 某 一 精度 和 细 
节 层 次 上 提供 系统 的 抽象 ， 而 我 们 又 可 
以 通过 分 析 模 型 获得 对 所 开发 系统 的 更 
好 理解 。 按 照 对 象 建 模 组 织 (OMG ) 的 
说 法 ,“ 建 模 就 是 在 编码 之 前 对 软件 应 用 
的 设计 ”。 

在 基于 模型 的 软件 设计 和 开发 中 ， ы Алин 
软件 建 模 被 作为 软件 开发 过 程 的 一 个 根 
本 性 的 部 分 。 模 型 在 系统 的 实现 之 前 进 
行 构造 和 分 析 ， 并 用 于 指导 后 续 的 实现 
过 程 。 

我 们 可 以 通过 从 多 个 不 同 的 角度 
(又 称 为 多 视图 ) 考虑 系统 以 更 好 地 理 
解 系统 (Gomaa 2006 ; Gomaa and Shin 
2004 )， 例 如 软件 系统 的 需求 模型 НХ 
模型 和 动态 模型 。 图 形 化 建 模 语言 ( 例 
如 UML) 有 助 于 对 不 同 视图 的 开发 、 理 
解 和 交流 。 

本 章 介 绍 了 面向 对 象 方 法 和 表示 法 、 
软件 建 模 和 体系 结构 设计 概览 以 及 对 于 
模型 驱动 体系 结构 ( MDA ) A UML 的 简介 。 此 外 ， 本 章 还 简要 介绍 了 软件 设计 方法 的 发 展 、 
面向 对 象 分 析 和 设计 方法 以 及 并 发 、 分 布 式 和 实时 设计 方法 。 


12 面向 对 象 方法 与 统一 建 模 语言 


面向 对 象 概 念 在 软件 分 析 和 设计 中 十 分 重要 ， 因 为 这 些 概念 与 软件 的 可 修改 性 、 适 应 性 
和 演化 中 的 根本 性 问题 相关 。 面 向 对 象 方法 基于 信息 隐藏 、 类 和 继承 的 概念 。 信 息 隐 藏 可 以 
使 得 系统 模块 独立 ， 从 而 具有 更 好 的 可 修改 性 和 可 维护 性 。 继 承 则 使 得 我 们 可 以 以 一 种 系统 
化 的 方式 对 类 进行 调整 。 








b) 埃及 的 大 金字 塔 
图 1-1 建 模 和 建筑 的 例子 








随 着 软件 应 用 的 面向 对 象 分 析 和 设计 方法 及 表示 法 的 流行 ， 统 一 建 模 语 言 (UML) 被 提 
出 ， 从 而 为 面向 对 象 模 型 的 描述 提供 了 一 种 标准 化 的 图 形 语言 和 表示 法 。 然 而 ， 由 于 UML 
是 一 种 与 方法 学 无 关 的 语言 ， 因 此 需要 与 面向 对 象 分 析 和 设计 方法 一 起 使 用 。 因 为 UML Ж 
在 是 描述 面向 对 象 模型 的 标准 化 的 图 形 语言 和 表示 法 ， 因 此 本 书 将 通 篇 使 用 UML 表示 法 。 

现代 的 面向 对 象 分 析 和 设计 方法 是 基于 模型 的 ， 并 且 综 合 使 用 了 用 例 建 模 、 静 态 建 模 、 
状态 机 建 模 和 对 象 交互 建 模 。 几 乎 所 有 现代 的 面向 对 象 方法 都 使 用 UML 表示 法 来 描述 软件 
需求 、 分 析 和 设计 模型 (Booch, Rumbaugh, and Jacobson 2005 ; Fowler 2004 ; Rumbaugh, 
Booch，and Jacobson 2005 )。 

在 用 例 建 模 中 ， 系 统 的 功能 性 需求 按照 用 例 和 参与 者 进行 定义 。 静 态 建 模 提 供 了 系统 的 
结构 化 视图 。 类 按照 其 属性 以 及 与 其 他 类 的 关系 进行 定义 。 动 态 建 模 提 供 了 系统 的 行为 视图 。 
用 例 是 通过 对 象 之 间 的 交互 来 实现 的 。 对 象 交 互 图 用 于 显示 对 象 之 间 是 如 何 通信 以 实现 用 例 
的 。 系 统 与 状态 相关 的 方面 则 使 用 状态 图 进行 定义 。 


1.3 软件 体系 结构 设计 


软件 体系 结构 ( Bass，Clements，and Kazman 2003 ; Shaw and Garlan 1996 ) 将 系统 的 总 
体 结构 (包括 构件 及 其 连接 关系 ) 与 各 个 构件 的 内 部 细节 相 分离 。 对 于 构件 及 其 连接 关系 的 
强调 有 时 被 称 为 全 局 性 的 编程 ， 而 单个 构件 的 详细 设计 被 称 为 局 部 性 的 编程 。 

软件 体系 结构 可 以 在 不 同 的 细节 层次 上 进行 描述 。 在 较 高 的 细节 层次 上 ， 体 系 结构 可 以 
描述 软件 系统 是 如 何 分解 为 子 系统 的 。 在 较 低 的 细节 层次 上 ,体系 结构 可 以 描述 子 系 统 是 如 
何 分 解 为 模块 或 构件 的 。 这 些 不 同 层 次 上 的 体系 结构 强调 的 都 是 子 系统 /构件 的 外 部 视图 ， 
即 子 系统 / 构件 所 提供 和 需要 的 接口 以 及 与 其 他 子 系统 / 构件 的 连接 关系 。 

设计 软件 体系 结构 的 时 候 应 当 考 虑 系统 的 软件 质量 属性 。 这 些 属性 与 体系 结构 如 何 满足 
重要 的 非 功 能 性 需求 相关 ， 例 如 性 能 、 安 全 性 和 可 维护 性 等 。 

软件 体系 结构 有 时 被 称 为 高 层 设 计 。 软 件 体系 结构 可 以 从 不 同 的 视图 进行 描述 ( 见 1.7 
节 )， 重 要 的 是 保证 体系 结构 同时 满足 功能 性 〈 软件 必须 做 什么 ) 和 非 功 能 性 ( 软件 应 当做 得 
多 好 ) 软件 需求 。 软 件 体 系 结构 同时 也 是 详细 设计 和 实现 ( 此 时 开发 团队 一 般 会 变 得 更 大 ) 
的 出 发 点 。 


14 ”方法 和 表示 法 


本 节 定 义 重要 的 软件 设计 相关 术语 。 

软件 设计 表示 法 是 一 种 使 用 图 形 或 文本 方式 或 同时 使 用 图 形 和 文本 描述 软件 设计 的 方法 。 
例如 ， 类 图 是 一 种 图 形 化 的 设计 表示 法 ， 而 伪 代 码 是 一 种 文本 化 的 设计 表示 法 。UML 是 一 种 
针对 面向 对 象 软件 应 用 的 图 形 化 表示 法 。 设 计 表 示 法 为 如 何 进行 软件 设计 给 出 了 一 些 方面 的 
建议 ， 但 并 未 为 如 何 产生 设计 提供 一 种 系统 化 的 方法 。 

软件 设计 思想 是 一 种 可 以 用 于 设计 系统 的 根本 性 的 思想 。 例 如 ， 信 息 隐 藏 是 一 种 软件 设 
计 思 想 。 

软件 设计 策略 是 一 种 对 设计 的 整体 性 规划 和 方向 性 指导 。 例 如 ， 面 向 对 象 的 分 解 是 一 种 
软件 设计 策略 。 

软件 结构 组 织 准则 是 用 于 帮助 设计 者 将 软件 系统 组 织 为 构件 的 启发 式 规则 或 指导 方针 。 
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例如 ， 对 象 结构 设计 准则 为 如 何 将 系统 分 解 为 对 象 提供 了 指导 方针 。 

软件 设计 方法 是 一 种 描述 了 用 于 在 给 定 的 应 用 系统 软件 需求 基础 上 创建 一 个 设计 方案 的 
步骤 序列 的 系统 化 方法 。 这 种 方法 可 帮助 设计 者 或 设计 团队 确定 需要 做 出 的 决策 、 做 出 决策 
的 顺序 以 及 决策 时 使 用 的 结构 设计 准则 。 设 计 方 法 建立 在 一 组 设计 思想 基础 上 ， 使 用 一 种 或 
多 种 设计 策略 ， 并 且 使 用 某 种 设计 表示 法 描述 所 得 到 的 设计 。 在 一 个 给 定 的 设计 步骤 中 ,， М 
计 方 法 可 能 会 提供 一 组 结构 设计 准则 来 帮助 设计 者 将 系统 分 解 为 构件 。 

协作 的 对 象 建 模 和 设计 方法 (Collaborative Object Modeling and Design Method, COMET ) 
使 用 UML 表示 法 来 描述 设计 。COMET 基于 信息 隐藏 、 类 、 继 承 和 并 发 任务 等 设计 思想 。 该 
方法 使 用 并 发 对 象 设计 的 设计 策略 ， 该 策略 将 软件 系统 的 结构 组 织 为 一 组 主动 和 被 动 对 象 并 
且 定 义 它 们 相互 之 间 的 接口 。 此 外 ， 该 方法 还 为 分 析 过 程 提供 了 结构 设计 准则 来 帮助 将 系统 
的 结构 组 织 为 对 象 ， 而 且 为 设计 过 程 提 供 了 附加 的 准则 来 确定 子 系统 和 并 发 任务 。 


1.5 COMET: 一 种 基于 UML 的 软件 应 用 建 模 和 设计 方法 


本 书 描述 了 一 种 称 为 COMET 的 基于 UML 的 软件 建 模 和 体系 结构 设计 方法 。COMET 是 
一 种 迭代 的 用 例 驱 动 和 面向 对 象 的 软件 开发 方法 ， 涵 盖 了 软件 开发 生存 周期 的 需求 、 分 析 和 
设计 建 模 阶段 。 系 统 的 功能 性 需求 被 定义 为 参与 者 和 用 例 。 每 个 用 例 定义 了 一 个 或 多 个 参与 
者 与 系统 之 间 的 交互 序列 。 用 例 可 以 在 各 种 不 同 的 细节 层次 上 进行 考虑 。 在 需求 模型 中 ， 系 
统 的 功能 性 需求 被 定义 为 参与 者 和 用 例 。 在 分 析 模 型 中 ， 用 例 被 具体 化 为 参与 用 例 的 对 象 及 
其 交互 关系 。 而 设计 模型 中 则 会 开发 软件 体系 结构 ， 考 虑 分 布 、 并 发 和 信息 隐藏 等 问题 。 


1.6 UML 标准 


本 节 简 要 回顾 UML 如 何 逐 步 发 展 成 为 描述 面向 对 象 设计 的 标准 建 模 语言 和 表示 法 。 
UML 的 发 展 历 史 在 Kobryn (1999) 中 有 详细 介绍 。UML 0.9 统一 了 Booch, Jacobson ( 1992 ) 
和 Rumbaugh et al. (1991) 所 述 的 表示 法 。 这 一 版 本 与 各 种 厂商 和 系统 集成 商 的 参与 一 起 构 
ЖТ UML 标准 化 工作 的 基础 。 这 一 标准 化 工作 的 结果 是 UML 1.0 提案 最 终 在 1997 年 1 月 
份 提交 给 OMG。 经 过 一 些 修改 后 ， 最 终 的 UML 1.1 提案 于 当年 晚 些 时 候 提 交 给 OMG, ， 并 在 
1997 年 11 月 被 采用 作为 一 种 对 象 建 模 标准 。 

OMG 将 UML 作为 一 项 标准 进行 维护 。 该 标准 被 采用 的 第 一 个 版 本 是 UML 1.3， 随 后 
的 UML 1.4 Ail 1.5 版 本 有 一 些 较 小 的 修订 。2003 年 的 UML 2.0 版 本 进行 了 一 次 较 大 的 修订 。 
关于 UML 的 最 新 参考 书 一 般 都 基于 UML 2.0 版 本 ， 包 括 Booch, Rumbaugh, and Jacobson 
(2005 )、Rumbaugh，Booch，and Jacobson ( 2005 )、Fowler ( 2004 ), Eriksson et al. ( 2004 ) 
以 及 Douglass ( 2004 ) 这 些 书 的 修订 版 。 自 此 之 后 UML 标准 还 有 一 些 较 小 的 修订 。UML 标 
准 的 当前 版 本 被 称 为 UML 2. 


基于 UML 的 模型 驱动 体系 结构 


按照 ома 的 观点 ,“ 建 模 是 软件 应 用 在 编码 之 前 的 设计 "。OMSG 积极 推动 着 在 模型 驱动 
的 软件 体系 结构 中 将 UML 模型 作为 实现 之 前 的 软件 体系 结构 建 模 表示 。OMG 认为 UML 独 
立 于 特定 的 方法 学 ， 是 一 种 描述 面向 对 象 分 析 和 设计 结果 的 表示 法 ， 其 中 的 分 析 和 设计 过 程 
可 以 采用 各 种 不 同 的 方法 学 。 
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UML 模型 可 以 是 平台 无 关 模 型 (platform-independent model, PIM) 也 可 以 是 平台 相关 
模型 《platform-specific model, PSM )。PIM 是 一 种 在 采用 特定 平台 的 决策 做 出 之 前 描述 软件 
体系 结构 的 精确 模型 。 首 先 开发 РМ 特别 有 用 ， 因 为 同一 个 РІМ 可 以 映射 到 不 同 的 中 间 件 平 
G&L, 例如 COM、CORBA、.NET、J2EE、Web Services 或 其 他 Web 平台 。 本 书 中 介绍 的 方 
法 使 用 模型 驱动 体系 结构 的 概念 开发 基于 构件 的 软件 体系 结构 ， 并 将 其 表示 为 UML 平台 无 
Е (РІМ )。 


1.7 软件 体系 结构 的 多 视图 


软件 体系 结构 可 以 从 不 同 的 角度 进行 考虑 ， 称 为 不 同 的 视图 。Kruchten ( Kruchten 1995 ) 
提出 了 软件 体系 结构 的 4+1 视图 模型 ， 提 倡 软件 体系 结构 的 多 视图 建 模 方法 ， 其 中 用 例 视 图 
位 于 中 心 位 置 ( 4+1 视图 中 的 1 )。 这 些 视图 包括 : 逻辑 视图 ， 一 种 静态 建 模 视图 ; 进程 视图 ， 
一 种 并 发 进程 或 任务 视图 ; 开发 视图 ， 一 种 子 系统 和 构件 设计 视图 ; 物理 视图 ， 一 种 反映 物 
理 拓扑 结构 及 连接 关系 的 视图 。Hofmeister et al. (2000) 描述 了 工业 界 对 于 软件 体系 结构 的 
一 种 观点 ， 包 括 四 个 视图 :一 个 概念 视图 ， 描 述 主要 的 设计 元 素 及 其 间 的 关系 ;一 个 代码 视图 ， 
将 源 代码 组 织 为 对 象 代 码 、 函 数 库 和 目录 ; 模块 视图 ， 由 子 系统 和 模块 组 成 ;执行 视图 ， 描 
述 了 并 发 和 分 布 式 执行 方面 。 

在 本 书 中 ,我 们 将 描述 UML 中 不 同 的 软件 体系 结构 建 模 视图 。 这 些 视图 包括 : 
用 例 视图 。 该 视图 是 一 种 功能 性 需求 视图 ， 是 软件 体系 结构 设计 的 输入 。 每 个 用 例 描 
述 了 一 个 或 多 个 参与 者 ( 外 部 用 户 ) 与 系统 之 间 的 交互 序列 。 
о 静态 视图 。 该 视图 用 类 以 及 类 间 关 系 描 述 体系 结构 ， 其 中 的 关系 包括 关联 、 整 体 / 部 
分 (组 合 或 聚合 )、 泛 化 / 特 化 关系 。 表 示 为 UML ЖИ. 
动态 交互 视图 。 该 视图 通过 对 象 以 及 对 象 间 的 消息 通信 来 描述 体系 结构 。 该 视图 也 可 
以 用 来 描述 特定 场景 的 执行 序列 。 表 示 为 UML 通信 图 。 
动态 状态 机 视图 。 一 个 控制 构件 的 内 部 控制 和 定 序 可 以 用 状态 机 来 描述 。 表 示 为 UML 
状态 图 。 
结构 构件 视图 。 该 视图 用 构件 来 描述 软件 体系 结构 ， 构 件 间 通过 端口 互联 ， 支 持 供给 
接口 和 请 求 接口 的 描述 。 表 示 为 UML 结构 化 类 图 。 
о 动态 并 发 视图 。 该 视图 将 软件 体系 结构 描述 为 在 分 布 式 结 点 上 执行 并 且 通 过 消息 进行 
通信 的 并 发 构件 。 表 示 为 UML 并 发 通信 图 。 
部 署 视图 。 该 视图 描述 分 布 式 体系 结构 中 构件 如 何 分 配 到 不 同 硬件 结 点 上 的 特定 配 
置 。 表 示 为 UML 部 署 图 。 


1.8 软件 建 模 和 设计 方法 的 发 展 


在 20 世纪 60 年 代 ， 软 件 程序 经 常 是 在 几乎 没有 进行 任何 系统 化 的 需求 分 析 和 设计 的 情 
况 下 开发 出 来 的 。 图 形 化 的 表示 法 ( 主要 是 流程 图 ) 经 常 在 编码 之 前 的 详细 设计 规划 中 作为 
文档 工具 或 者 设计 工具 使 用 。 创 建 子 程序 的 最 初 目的 是 通过 在 程序 中 不 同 的 部 分 调用 代码 块 
使 其 能 够 得 到 共享 。 很 快 ， 人 们 意识 到 子 程序 可 以 作为 一 种 构造 模块 化 系统 的 手段 ， 并 将 其 
用 作 一 种 项 目 管理 工具 。 程 序 可 以 被 划分 为 多 个 模块 ， 其 中 每 个 模块 可 以 由 单个 的 程序 员 进 
行 开 发 并 实现 为 一 个 子 程序 或 函数 。 
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随 着 结构 化 编程 在 20 世 纪 70 年 代 早 期 的 发 展 ， 自 顶 向 下 设计 以 及 逐步 精 化 的 思 
想 (Dahl 1972) 成 为 主流 的 程序 设计 方法 ， 其 目的 是 提供 系统 化 的 结构 化 程序 设计 方法 。 
Dijkstra Æ T.H.E. 操作 系统 的 设计 过 程 中 提出 了 最 早 的 软件 设计 方法 之 一 (Dijkstra 1968 ), 
该 方法 使 用 了 层次 化 的 体系 结构 。 这 是 第 一 个 用 于 并 发 系统 ( 即 操作 系统 ) 设计 的 设计 方法 。 

ЖЕ 20 世纪 70 年 代 中 晚期 ， 两 种 不 同 的 软件 设计 策略 占据 了 主导 地 位 : 面向 数据 流 的 设 
计 和 数据 结构 化 设计 。 结 构 化 设计 中 的 面向 数据 流 的 设计 方法 (参见 Budgen[2003] 中 的 概 
览 ) 是 最 早出 现 的 几 个 完整 、 全 面 的 设计 方法 之 一 。 该 方法 的 主要 思想 是 通过 考虑 数据 在 系 
统 中 的 流动 可 以 更 好 地 理解 系统 的 功能 。 该 方法 提供 了 一 种 开发 系统 数据 流 图 然后 将 其 映射 
为 结构 图 的 系统 化 方法 。 结 构 化 设计 引入 了 耦合 和 内 聚 准 则 来 评价 设计 质量 ， 强 调 基于 模块 
的 功能 分 解 以 及 模块 接口 的 定义 。 基 于 数据 流 图 开发 的 结构 化 设计 中 第 一 个 部 分 则 被 细 化 和 
扩展 成 了 一 种 全 面 的 分 析 方法 ， 即 结构 化 分 析 (参见 Budgen[2003] 中 的 概览 )。 

另 一 种 软件 设计 方法 是 数据 结构 化 设计 。 该 方法 的 观点 是 通过 考虑 数据 结构 获得 对 问 
题 结构 的 充分 理解 。 因 此 ， 该 方法 强调 首先 设计 数据 结构 然后 基于 数据 结构 设计 程序 结构 。 
使 用 这 种 策略 的 两 种 主要 的 设计 方法 是 Jackson 结构 化 方法 ( Jackson 1983 ) 和 Warnier/Orr 
方法 。 

在 数据 库 领 域 中 ，J 逻 辑 数据 和 物理 数据 分 离 的 思想 是 开发 数据 库 管理 系统 的 关键 。 有 很 
多 方法 都 强调 数据 库 的 逻辑 设计 ， 包括 Chen 引入 的 实体 - 关系 建 模 。 

Parnas (1972) 关于 信息 隐藏 的 观点 对 软件 设计 做 出 了 巨大 的 贡献 。 早 期 系统 (甚至 是 
那些 已 经 考虑 了 模块 化 设计 的 系统 ) 的 一 个 主要 问题 来 自 于 全 局 数据 的 广泛 使 用 ， 这 使 得 这 
些 系 统 很 容易 出 错 且 难 以 修改 。 信 息 隐 藏 为 大 量 减 少 全 局 数据 的 使 用 提供 了 一 种 方法 。 

20 世纪 70 年 代 后 期 MASCOT 表示 法 以 及 此 后 的 MASCOT 设计 方法 的 提出 是 对 并 发 和 
实时 系统 设计 的 一 个 重要 贡献 。MASCOT 在 数据 流 方 法 基础 上 ， 对 任务 之 间 基 于 消息 通信 通 
道 或 者 数据 池 (封装 了 共享 数据 结构 的 信息 隐藏 模块 ) 的 通信 方式 进行 了 形式 化 。 任 务 只 能 
通过 调用 通道 或 数据 池 提 供 的 访问 程序 间接 地 访问 通道 或 数据 池 中 的 数据 。 访 问 程序 还 可 以 
对 数据 访问 进行 同步 ( 通常 使 用 信号 量 )， 从 而 使 访问 数据 的 任务 无 需 关心 任何 同步 问题 。 

软件 设计 方法 在 20 世纪 80 年 代 逐 渐 成 熟 起 来 ， 同 时 出 现 了 几 种 新 的 系统 设计 方法 。 
Parnas 在 海军 研究 实验 室 ( Naval Research Lab, NRL) 工作 期 间 探 索 了 信息 隐藏 方法 在 大 规 
模 软 件 设计 中 的 使 用 ， 由 此 导致 了 海军 研究 实验 室 软件 成 本 降低 方法 (Naval Research Lab 
Software Cost Reduction Method ) ( Parnas, Clements, and Weiss 1984 )。 在 并 发 和 实时 系统 上 
应 用 结构 化 分 析 和 结构 化 设计 方法 的 工作 导致 了 实时 结构 化 分 析 和 设计 (Real-Time Structured 
Analysis and Design, RTSAD ) 方法 (参见 Gomaa[1993] 概览 ) 以 及 实时 系统 设计 (Design 
Approach for Real-Time Systems, DARTS ) 方法 (Gomaa 1984 ) 的 产生 。 

另 一 种 在 20 世纪 80 年 代 早 期 出 现 的 软件 开发 方法 是 Jackson 系统 设计 (Jackson System 
Development, JSD ) 方法 (Jackson 1983 )。JSD 方法 将 软件 设计 视 为 对 现实 世界 的 模拟 ， 强 
调 使 用 并 发 任务 对 问题 域 中 的 实体 进行 建 模 。 该 方法 是 较 早 倡导 设计 应 该 首先 对 现实 进行 建 
模 的 方法 之 一 ， 在 这 一 点 上 早 于 面向 对 象 分 析 方 法 。 系 统 被 视 为 对 现实 世界 的 模拟 ， 并 被 设 
计 为 一 个 并 发 任务 的 网 络 ， 其 中 每 个 现实 世界 实体 使 用 并 发 任务 进行 建 模 。JSD 方法 同时 还 
突破 了 当时 已 成 为 惯性 思维 的 自 顶 向 下 的 设计 思想 ， 对 软件 设计 采用 了 一 种 中 间 癌 外 的 行为 
性 建 模 方法 。 该 方法 是 对 象 交 互 建 模 的 先导 ， 而 对 象 交互 建 模 则 是 现代 面向 对 象 开发 的 一 个 
重要 内 容 。 








1.9 面向 对 象 分 析 和 设计 方法 的 发 展 
20 世纪 80 年 代 中 晚期 ， 面 向 对 象 编程 的 流行 和 成 功 使 得 几 种 面向 对 象 设 计 方 法 相继 出 现 ， 


包括 Booch, Wirfs-Brock, Wilkerson, and Wiener ( 1990 )、Rumbaugh et al. (1991), ЗШаег and [9] 


Mellor (1988, 1992) 以 及 Coad and Yourdon ( 1991，1992 )。 这 些 方 法 所 强调 的 重点 在 于 问题 
域 建 模 、 信 息 隐 藏 和 继承 。 

Parnas 倡导 将 信息 隐藏 作为 一 种 设计 更 加 独立 的 模块 的 方法 ， 这 种 独立 的 模块 可 以 在 对 
其 他 模块 影响 很 小 甚至 不 造成 任何 影响 的 情况 下 进行 修改 。Booch 将 面向 对 象 思想 引入 到 设 
计 中 ， 最 初 与 信息 隐藏 一 起 应 用 到 基于 Ада 的 系统 的 面向 对 象 设计 中 ， 然 后 扩展 为 在 面向 对 
象 设计 中 使 用 信息 隐藏 、 类 和 继承 。Shlaer and Mellor ( 1988 )、Coad and Yourdon ( 1991) № 
其 他 人 将 面向 对 象 思想 引 人 到 分 析 中 。 与 结构 化 方法 相 比 ,面向 对 象 方 法 被 普遍 认为 提供 了 
一 种 更 加 平滑 的 从 分 析 到 设计 的 过 渡 。 

面向 对 象 分 析 方 法 将 面向 对 象 思想 应 用 到 软件 生存 周期 的 分 析 阶 段 ， 强 调 识别 问题 域 中 
的 现实 世界 对 象 并 将 其 映射 为 软件 对 象 。 在 对 象 建 模 上 最 初 的 设想 是 源 自 于 逻辑 数据 库 设 计 
中 使 用 的 信息 建 模 ( 特别 是 实体 关系 (E-R ) 建 模 ， 更 一 般 地 说 是 语义 数据 建 模 ) 的 静态 建 
模 方法 。 实 体 关系 建 模 中 的 实体 是 问题 域 中 的 信息 密集 型 对 象 。 实 体 、 实 体 的 属性 以 及 实体 
间 的 关系 在 实体 关系 图 中 进行 确定 和 描述 ; 重点 完全 在 数据 建 模 上 。 在 设计 过 程 中 ， 实 体 关 
系 模型 被 映射 到 数据 库 ( 通常 是 关系 数据 库 ) 中 。 在 面向 对 象 分 析 中 ， 问 题 域 中 的 对 象 被 识 
别 和 建 模 为 软件 类 ， 然 后 确定 每 个 类 的 属性 以 及 类 之 间 的 关系 (Coad 1991 ; Rumbaugh et al. 
1991; Shlaer and Mellor 1988 )。 

面向 对 象 的 静态 建 模 中 的 类 与 实体 关系 建 模 中 的 实体 类 型 的 主要 区 别 在 于 类 有 操作 而 
实体 类 型 没有 操作 。 此 外 ， 信 息 建 模 只 对 存储 在 数据 库 中 的 持久 化 实体 进行 建 模 ， 而 静态 的 
对 象 建 模 中 也 会 对 其 他 问题 域 中 的 类 进行 建 模 。 信 息 建 模 中 也 包含 了 聚合 和 泛 化 / 特 化 这 样 
更 加 高 级 的 概念 。 在 UML 之 前 使 用 最 广泛 的 静态 对 象 建 模 表示 法 是 对 象 建 模 技 术 (Object 
Modeling Technique, OMT ) (Rumbaugh et al. 1991 )。 

静态 对 象 建 模 也 称 为 类 建 模 和 对 象 建 模 ， 因 为 其 中 包含 确定 对 象 所 属 的 类 并 且 在 类 图 
中 描述 类 与 类 之 间 的 关系 。 领 域 建 模 这 一 术语 也 用 来 指 对 问题 域 的 静态 建 模 ( Rosenberg and 
Scott 1999; Shlaer and Mellor 1992 ), 

早期 的 面向 对 象 分 析 和 设计 方法 通过 信息 隐藏 和 继承 强调 软件 开发 的 结构 性 方面 而 忽 
视 了 动态 方面 。OMT (Rumbaugh et al. 1991 ) 的 一 个 重要 贡献 在 于 清晰 地 表明 了 动态 建 模 
也 是 同等 重要 的 。 除 了 为 对 象 图 引入 静态 建 模 表示 法 外 ，OMT 还 展示 了 如 何 使 用 状态 图 进 
行动 态 建 模 以 显示 主动 对 象 与 状态 相关 的 行为 及 如 何 使 用 顺序 图 来 显示 对 象 间 的 交互 序列 。 
Rumbaugh et al. (1991) 使 用 状态 图 ， 这 是 一 种 最 初 由 Harel (1988, 1998) 所 设想 的 层次 化 
的 状态 转换 图 ， 用 来 建 模 主动 对 和 象 。Shlaer and Mellor (1992) 也 是 用 状态 转换 图 来 建 模 主 动 
对 象 。Booch 最 初 使 用 对 象 图 来 显示 实例 级 的 对 象 间 交 互 ， 后 来 对 交互 进行 顺序 编号 从 而 更 
加 清楚 地 描述 对 象 间 的 通信 。 

Jacobson (1992) 为 系统 的 功能 性 需求 的 建 模 引 入 了 用 例 的 概念 ， 还 使 用 顺序 图 来 描述 
参与 一 个 用 例 的 对 象 之 间 的 交互 序列 。 用 例 的 概念 是 Jacobson 的 面向 对 象 软件 工程 生存 周期 
中 所 有 阶段 的 基础 。 用 例 的 概念 已 经 对 现代 面向 对 象 软件 开发 产生 了 深远 的 影响 。 

ЖЕ UML 之 前 ， 还 有 其 他 一 些 试图 统一 不 同 的 面向 对 象 方法 和 表示 法 的 尝试 ， 包 括 





Fusion (Coleman et al. 1993 ) 和 Texel and Williams (1997) 的 著作 。UML 表示 法 最 初 由 
Booch, Jacobson 和 Rumbaugh 提出 ， 甚 目的 是 集成 用 例 建 模 、 静 态 建 模 和 动态 建 模 ( 使 用 状 
态 图 和 对 象 交 互 建 模 ) 表示 法 ， 这 些 将 在 第 2 章 中 撒 述 。 其 他 方法 学 家 也 对 UML 的 发 展 做 
出 了 贡献 。Cobryn[1999] 和 Selic (1999) 有 一 个 关于 UML 是 如 何 演化 的 以 及 在 未 来 会 怎样 
演化 的 有 趣 的 讨论 。 


1.10 并发、 分 布 式 和 实时 设计 方法 


实时 系统 的 并 发 设计 方法 (Concurrent Design Approach for Real-Time Systems, CODARTS ) 
(Gomaa 1993 ) 结合 了 早期 的 并 发 设计 、 实 时 设计 和 早期 的 面向 对 象 设 计 方 法 ， 强 调 信息 隐藏 
模块 的 构造 和 并 发 任务 的 构造 。 

Octopus ( Awad, Kuusela, and Ziegler 1996) 是 一 种 基于 用 例 、 静 态 建 模 、 对 象 交 互 和 状 
态 图 的 实时 设计 方法 。ROOM (Selic, Gullekson, and Ward 1994 ) 是 一 种 与 CASE ( Computer- 
Assisted Software Engineering， 计 算 机 辅助 软件 工程 ) 工具 ObjecTime 紧密 联系 的 面向 对 象 的 实 
时 设计 方法 ， 它 是 基于 参与 者 (actor ) 的 ， 即 一 种 使 用 ROOMcharts ( 一 种 状态 图 的 变种 ) E 
模 的 主动 对 象 。ROOM 模型 可 以 被 执行 ， 因 此 可 以 作为 系统 的 早期 原型 使 用 。 

针对 大 规模 系统 的 动态 建 模 ，Buhr (1996) 引入 了 一 个 有 趣 的 概念 ， 称 为 用 例 映 射 (use 
case map )， 它 是 基于 用 例 的 概念 产生 的 。 

针对 基于 UML 的 实时 软件 开发 ，Douglass (2004, 1999) 提供 了 一 个 关于 UML 如 何 应 
用 于 实时 系统 开发 的 全 面 介 绍 。 

针对 并 发 、 实 时 和 分 布 式 应 用 设计 的 COMET 方法 的 一 个 早期 版 本 在 Gomaa (2000 ) 
中 进行 了 介绍 ， 这 个 版 本 是 基于 UML 1.3 的 。 这 本 新 的 教科 书 在 UML 2 的 基础 上 扩展 了 
COMET 方法 ， 更 加 强调 软件 体系 结构 ， 并 且 涉 及 更 大 范围 内 的 软件 应 用 ， 如 面向 对 象 软件 
体系 结构 、 客 户 端 /服务 器 软件 体系 结构 、 面 向 服务 的 体系 结构 、 基 于 构件 的 软件 体系 结构 、 
并 发 和 实时 软件 体系 结构 、 软 件 产品 线 体系 结构 等 。 


1.11 А 


本 章 介绍 了 面向 对 象 方法 和 表示 法 、 软 件 体系 结构 设计 和 UML， 还 简要 描述 了 软件 设计 
方法 、 面 向 对 象 分 析 和 设计 方法 以 及 并 发 、 分 布 式 和 实时 设计 方法 的 发 展 历史 。 第 2 章 将 对 
UML 表示 法 进行 概要 介绍 。 第 3 章 描述 软件 生存 周期 及 方法 。 第 4 章 介绍 软件 设计 和 体系 结 
构 概 念 。 第 5 章 描 述 针 对 COMET 方法 的 基于 用 例 的 软件 生存 周期 。 


练习 


选择 题 ( 每 道 题 选择 一 个 答案 ) 
1. 什么 是 软件 建 模 ? 


(а) 开发 软件 模型 (b) 在 编码 之 前 设计 软件 应 用 
(с) 开发 软件 图 (4) 开发 软件 原型 


2. 什么 是 统一 建 模 语言 ? 
(а) 描述 面向 对 象 模型 的 编程 语言 
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(b) 绘制 面向 对 象 模型 的 画图 工具 

(с) 描述 面向 对 象 模型 的 图 形 化 语言 

Са) 描述 面向 对 象 模型 的 一 种 标准 化 的 图 形 语言 和 表示 法 
3. 什么 是 软件 体系 结构 ? 


(a) 一座 建筑 之 中 的 软件 (b) 一 个 客户 端 /服务 器 系统 的 结构 
(с) 软件 系统 的 总 体 结构 (4) 软件 类 及 其 关系 

4. 什么 是 软件 设计 表示 法 ? 

(а) 关于 软件 设计 的 注释 和 说 明 Cb ) 软件 的 图 形 化 或 文本 描述 

(с) 软件 的 文档 化 (а) 产生 一 个 设计 的 一 种 系统 化 方法 


5. 什么 是 软件 设计 思想 ? 

(а) 软件 的 图 形 化 或 文本 描述 

(6) 软件 的 文档 化 

Co) 可 以 应 用 于 软件 系统 设计 的 一 种 根本 性 的 思想 

Cd) 产生 一 个 设计 的 一 种 系统 化 的 方法 

6. 什么 是 软件 设计 策略 ? 

(а) 软件 的 图 形 化 或 文本 描述 

(b ) 可 以 应 用 于 软件 系统 设计 的 一 种 根本 性 的 思想 

(с) 产生 一 个 设计 的 一 种 系统 化 的 方法 

(4) 开发 一 个 设计 的 总 体 计划 和 指导 

7. 什么 是 软件 结构 组 织 准则 ? 

(a) 可 以 应 用 于 软件 系统 设计 的 一 种 根本 性 的 思想 

Cb) 产生 一 个 设计 的 一 种 系统 化 的 方法 

(с) 用 于 帮助 将 软件 系统 组 织 为 一 组 构件 的 指导 方针 

(4) 开发 一 个 设计 的 总 体 计划 

8. 什么 是 软件 设计 方法 ? 

(а) 产生 一 个 设计 的 一 种 系统 化 的 方法 

(b ) 用 于 帮助 将 软件 系统 组 织 为 一 组 构件 的 指导 方针 

(с) 开发 一 个 设计 的 总 体 计 划 [12] 
(а) 软件 的 图 形 化 或 文本 描述 
9. 什么 是 平台 无 关 模型 (PIM 7 

(a) 在 做 出 针对 特定 硬件 平台 的 承诺 之 前 的 一 种 软件 平台 

(b) 在 做 出 针对 特定 平台 的 承诺 之 前 的 一 种 精确 的 软件 体系 结构 模型 
(с) 映射 到 特定 平台 上 的 一 种 精确 的 软件 体系 结构 模型 

(4) 软件 的 图 形 化 或 文本 描述 

10. 什么 是 平台 相关 模型 (PSM ) 7 

(a) 一 种 特定 的 硬件 平台 

(o) 在 做 出 针对 特定 平台 的 承诺 之 前 的 一 种 精确 的 软件 体系 结构 模型 
(с) 映射 到 特定 平台 上 的 一 种 精确 的 软件 体系 结构 模型 

(4) 软件 的 图 形 化 或 文本 描述 [13] 
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UML 表示 法 概述 





统一 建 模 语 言 (UML ) 是 COMET 方法 使 用 的 表示 法 。 本 章 提供 了 对 UML 表示 法 的 简 
要 概述 。 自 从 1997 年 首次 作为 一 个 标准 被 采用 之 后 ，UML 表示 法 就 一 直 在 不 断 地 演化 。 对 
于 该 标准 的 主要 修订 发 生 在 2003 年 ， 因 此 UML 2 成 为 了 当前 的 标准 版 本 。 这 个 标准 的 之 前 
版 本 被 称 为 UML 1.x。 

UML 表示 法 的 规模 在 过 去 几 年 大 幅 增 长 ， 现 在 它 已 支持 对 许多 图 的 表示 。 本 书 采 用 的 方 
法 与 Fowler (2004) 采用 的 一 样 ， 即 只 使 用 了 UML 表示 法 中 具有 明显 优点 的 部 分 。 本 章 描 
RT UML 表示 法 中 适用 于 COMET 方法 的 主要 特征 。 由 于 已 有 很 多 书籍 介绍 完整 的 UML K 
示 法 ， 因 此 本 章 的 目的 不 是 完整 地 阐述 UML， 而 是 简要 概述 UML。 本 章 将 简要 描述 在 本 书 
中 使 用 到 的 每 一 个 UML 图 的 主要 特征 ， 而 省 略 一 些 较 少 使 用 的 特征 。 另 外 ， 本 章 也 会 简要 
解释 UML 2 和 UML 1.x 表示 法 之 间 的 不 同 之 处 。 


2.1 ОМЕН 


在 应 用 开发 中 ，UML 表示 法 支持 以 下 图 : 

用 例 图 (Use case diagram ), 2.2 节 对 其 进行 简要 描述 。 

类 图 (Class diagram ), 2.4 节 对 其 进行 简要 描述 。 

对 象 图 (Object diagram ) ( 类 图 的 一 个 实例 版 本 )，COMET 没有 使 用 该 图 。 

通信 图 (Communication diagram )， 在 UML 1.x 中 称 为 交互 图 ，2.5.1 节 中 对 其 进行 简 
要 描述 。 

顺序 图 ( Sequence diagram )，2.5.2 节 对 其 进行 简要 描述 。 

状态 机 图 ( State Machine diagram )，2.6 节 对 其 进行 简要 描述 。 

活动 图 ( Activity diagram ), COMET 未 广泛 使 用 该 图 ， 本 书 第 6 章 会 对 其 进行 简要 描述 。 
组 合 结构 图 ( Composite structure diagram )， 一 个 在 UML 2 中 新 引入 的 图 ， 这 种 图 
实际 上 更 适合 于 在 UML 平台 无 关 模 型 中 创建 分 布 式 构件 。 本 书 第 17 章 会 对 其 进行 
描述 。 

e 部 署 图 ( Deployment diagram ), 2.9 节 对 其 进行 简要 描述 。 

第 6 章 至 第 19 章 描 述 了 COMET 方法 是 如 何 使 用 这 些 UML 图 的 。 


22 用例 图 


一 个 参与 者 (actor) 发 起 一 个 用 例 (use сазе )。 用 例 定义 了 参与 者 与 系统 之 间 的 一 组 交 
互 序列 。 在 用 例 图 中 ， 参 与 者 用 一 个 人 形 图 标 表示 ， 系 统 则 用 一 个 方 框 来 表示 ， 一 个 用 例 表 
示 为 方 框 中 的 一 个 椭圆 。 通 信 关 联 ( communication association) 将 参与 者 与 他 们 参与 的 用 例 
进行 连接 。 用 例 之 间 的 关系 通过 包含 ( include ) 关系 和 扩展 (extend) 关系 进行 定义 。 用 例 图 
的 表示 法 如 图 2-1 所 示 。 
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Е 2-1 UML 表示 法 中 的 用 例 图 








23 RAR 


类 (class) AXZ (object) Æ UML 表示 法 中 被 描绘 成 方 框 ， 如 图 2-2 所 示 。 表 示 类 的 
方 框 总 是 包含 类 名 ， 并 且 可 选择 性 地 列 出 类 的 属性 (attribute ) 和 操作 (operation )。 当 同时 
描述 以 上 三 者 时 ， 方 框 的 顶部 区 域 放置 类 名 ， 中 部 区 域 放置 属 性 ， 底 部 区 域 放 置 操 作 。 


Class 


Class Class with attributes 


attributes 


Class with attributes and operations 


= 一 


Objects 
图 2-2 UML 表示 法 中 的 对 象 和 类 


为 了 区 分 类 (类 型 ) 和 对 象 ( 该 类 型 的 一 个 实例 )， 对 象 名 称 需要 带 有 下 划 线 。 可 以 在 对 
象 名 和 类 名 之 间 使 用 冒号 分 隔 来 完整 地 描绘 一 个 对 象 ， 例 如 anObiject:Class。 也 可 选择 性 地 隐 
藏 冒号 和 类 名 ， 仅 剩 下 对 象 名 ， 例 如 anObject。 另 一 种 方式 是 隐藏 对 象 名 ， 仅 在 冒号 后 显示 
类 名 ， 例 如 :Class。 正 如 2.4 节 描 述 的 那样 ， 类 和 对 象 会 在 多 种 UML 图 中 被 描绘 。 
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24 类 图 


在 类 图 中 ， 类 用 方 框 描绘 ， 类 之 间 的 静态 (永久 ) 关系 被 描绘 成 连接 方 框 之 间 的 连 
ko UML 表示 法 支持 以 下 三 种 类 之 间 的 主要 关系 类 型 : 关联 ( association )、 整 体 / 部 分 关系 
( whole/part relationship ) 和 泛 化 / 特 化 ( generalization/specialization relationship ) 关系 ， 这 些 
关系 如 图 2-3 所 示 。 第 四 种 关系 ， 即 依赖 关系 ( dependency relationship )， 经 常 被 用 来 表示 包 
之 间 是 如 何 进 行 关 联 的 ，2.7 节 将 对 其 进行 描述 。 






| 


Class 可 选 (0 或 1) 
oh cone) 
ял алия 


eae - сене 
名 称 的 阅读 方向 ) 导航 的 方向 ) 


Association 


a) 关联 
ДА 









SubclassA1 

组 合 层次 泛 化 / 特 化 

b) 聚合 和 组 合 层 次 с) 泛 化 / 特 化 层次 
图 2-3 UML 表示 法 中 类 图 内 的 关系 


SubclassA2 








2.4.1 KE 


一 个 关联 (association) 是 两 个 或 多 个 类 之 间 的 一 个 静态 的 、 结 构 化 的 关系 。 两 个 类 之 
间 的 关联 被 称 为 二 元 关联 (binary association )， 它 用 两 个 类 框 之 间 的 连 线 表示 ， 如 图 2-3a 
中 连接 classA 方 框 和 classB 方 框 的 连 线 。 一 个 关联 具有 一 个 名 字 ， 并 且 可 选择 性 地 具有 一 
个 黑色 小 箭头 来 表示 关联 名 称 的 阅读 方向 。 每 个 连接 类 的 关联 线 的 末端 标明 关联 的 多 重 性 
( multiplicity )， 多 重 性 指 的 是 一 个 类 的 多 少 个 实例 关联 到 另 一 个 类 的 一 个 实例 。 此 外 ， 可 以 
用 棍 状 箭头 描绘 导航 的 方向 。 

一 个 关联 的 多 重 性 (multiplicity ) 指 的 是 一 个 类 的 多 少 个 实例 可 能 和 男 一 个 类 的 单个 实 
例 有 关 ( 如 图 2-3a 的 右边 )。 一 个 类 的 多 重 性 可 以 是 一 个 (1)、 可 选 (0..1 )、 零 或 多 个 ( *), 
一 个 或 多 个 ( 1..* ), 或 者 特定 的 数值 范围 (m.n), HEP т Al и 是 数值 。 


2.4.2 ”聚合 和 组 合 层次 


AMAA EM (aggregation and composition hierarchy ) 是 整体 /部 分 (whole/part ) 的 
х. НАЯ (用 黑色 菱形 表示 ) 是 一 个 比 聚 合 关系 ( 用 空心 菱形 表示 ) 更 强 的 整体 /部 
分 关系 的 形式 。 蓉 形 与 聚合 或 组 合 中 ( ClassWhole ) 的 类 方 框 相连 接 ( 见 图 2-3b )。 
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2.4.3 泛 化 和 特 化 层次 


泛 化 / 特 化 层次 (generalization/specialization hierarchy ) 是 一 种 继承 关系 (inheritance 
relationship )。 泛 化 被 描绘 为 一 个 连接 子 类 (subclass) 到 父 类 (superclass) 的 具有 箭头 的 连 
线 ， 箭 头 与 表示 父 类 的 方 框 连接 ( 见 图 2-3c )。 


2.4.4 可 见 性 


可 见 性 (visibility ) 指 类 中 的 一 个 元 素 是 否 在 类 外 可 见 ， 如 图 2-4 所 示 。 在 类 图 中 摘 绘 
可 见 性 是 可 选 的 。 公 有 可 见 性 ( public visibility) 使 用 + 号 ， 表示 一 个 元 素 在 类 的 外 部 是 可 见 
的 。 私 有 可 见 性 (private visibility) 使 用 -号 ， 表示 一 个 元 素 只 在 定义 它 的 类 的 内 部 是 可 见 
的 ， 对 于 其 他 类 是 隐藏 的 。 受 保护 可 见 性 (protected visibility) 使 用 # 号 ， 表 示 一 个 元 素 在 定 
义 它 的 类 及 其 所 有 子 类 中 是 可 见 的 。 


ClassName 







SubclassA1 


- privateClassAttributes 


图 2-4 UML 表示 法 中 类 图 内 的 可 见 性 
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通信 图 和 顺序 图 是 UML 的 两 种 主要 类 型 的 交互 图 ， 它 们 用 来 描绘 对 象 间 是 如 何 进 行 交 互 
的 。 在 这 些 交 互 图 中 ， 对 象 用 长 方形 方 框 表 示 ， 对 象 的 名 字 不 需要 使 用 下 划 线 标 绘 。2.5.1 节 


和 2.5.2 节 将 描述 这 些 图 的 主要 特征 。 1: 输入 消息 








251 ”通信 图 
2: 内 部 消息 | 


objectB1 : ClassB 


通信 图 在 UML 1.x 中 被 称 为 协作 图 (collaboration 


:Actor 


diagram )， 它 展示 了 合作 对 象 间 如 何 通过 发 送 与 接收 消息 进 


行动 态 的 交互 。 通 信 图 描绘 了 交互 对 象 的 组 织 结构 。 其 中 ， 3*: 选 代 消息 
对 象 用 方 框 表 示 ， 连 接 方 框 的 线 代表 了 对 象 间 的 交互 。 与 这 
些 线 相 邻 的 带 有 标签 的 箭头 表示 了 对 象 间 消息 传递 的 名 字 和 





方向 。 同 时 ， 对 象 间 传 递 消息 的 顺序 被 进行 了 编号 。 通 信 图 的 ”| 
表示 法 如 图 2-5 所 示 。 其 中 ， 星 号 (+) 表示 一 个 可 选 的 迭代 ， 
即 一 条 消息 被 发 送 了 多 于 一 次 。 一 个 可 选 的 条 件 (condition) ш, ОМИ 
表示 一 条 消息 在 满足 特定 条 件 的 情况 下 才 会 被 发 送 。 


2.5.2 ”顺序 图 
顺序 图 是 另 一 种 说 明 对 象 间 交互 方式 的 图 ， 如 图 2-6 所 示 ， 顺 序 图 将 对 象 交 互通 过 时 间 
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序列 的 方式 进行 描绘 。 顺 序 图 具有 两 个 维度 ， 其 中 参与 交互 的 对 象 被 描绘 在 水 平方 向 ， 而 垂 
直方 向 代表 时 间 维 度 。 从 每 一 个 对 象 框 出 发 都 有 一 条 被 称 为 生命 线 (lifeline ) 的 垂直 虚线 。 
每 条 生命 线 可 以 选择 性 地 具有 一 个 使 用 双 实 线 表示 的 激活 杆 (activation bar， 图 中 未 示 出 ), 
它 用 来 表示 对 象 执行 的 时 间 。 


objectB1 : ClassB | | anObject : ClassC 
Е 一 一 
| i 1 
П | 上 
р р р 
р i 


: Actor 











1: 输入 消息 
， 2: 内 部 消息 
==» 
| 其 他 消息 
一 一 一 一 > 


| 4: 请 求 消息 


1 р 

1 1 1 р 

1 1 р ' 
1 


图 2-6 UML 表示 法 中 的 顺序 图 


参与 者 通常 显示 在 页 面 的 最 左 端 。 带 有 标签 的 水 平 箭头 代表 消息 。 仅 有 箭头 连接 的 源 对 
象 和 目标 对 象 是 相关 的 ， 消 息 从 源 对 象 发 送 到 目标 对 象 。 时 间 从 页 面 的 项 部 开始 增加 直至 底 
部 。 另 外 ， 消 息 之 间 的 间隔 是 不 相关 的 。 

UML 2 已 大 幅 扩 展 了 顺序 图 的 表示 法 ， 增 加 了 对 循环 和 条 件 的 描述 ， 这 些 内 容 在 第 9 章 
和 第 11 章 中 介绍 。 


26 ”状态 机 图 


在 UML 表示 法 中 ， 一 个 状态 转换 图 被 称 为 状态 机 图 。 本 书 使 用 状态 图 ( statechart ) 这 一 
更 为 通用 的 术语 。 在 UML 表示 法 中 ， 圆 角 框 表示 状态 ， 连 接 圆 角 框 的 弧 线 表示 转换 ， 如 图 
2-7 所 示 。 状 态 图 的 初始 状态 〈initial state) 用 一 个 始 于 小 黑 圆 圈 的 弧 线 表 示 。 终 结 状 态 (final 
state) EVEN, БИН НЕКА TH) SAR, Abt tL RRA Fes ( bull’s-eye ). 
状态 图 可 以 按 层次 分 解 ， 将 一 个 组 合 状态 分 解 成 为 一 组 子 状态 。 

在 表示 状态 转换 的 弧 线 上 ， 使 用 事件 [条 件 ]/ 动 作 (Event[Condition]/Action ) 进行 标 
id, BH (event) 引起 了 状态 的 转换 ， 当 事件 发 生 时 ， 为 了 发 生 转 换 ， 可 选 的 布尔 条 件 
(condition) 必须 为 真 。 可 选 的 动作 ( action ) 作为 转换 的 结果 被 执行 。 一 个 状态 可 具有 以 下 
任意 的 动作 : 

e 进入 动作 (entry action )， 它 在 进入 状态 的 时 候 执 行 

® 退出 动作 (exit action )， 它 在 退出 状态 的 时 候 执 行 

图 2-7 描述 了 一 个 被 分 解 为 顺序 的 子 状态 Al 和 A2 的 组 合 状 态 A。 在 这 种 情况 下 ， 状 态 
图 在 一 个 时 刻 内 只 会 处 于 一 个 子 状 态 ， 即 进入 第 一 个 子 状 态 Al 然后 进入 子 状态 A2。 图 2-8 
描述 了 一 个 被 分 解 为 正 交 区 域 ( orthogonal region ) BC 和 BD 的 组 合 状 态 B。 在 这 种 情况 下 ， 
状态 图 在 同一 个 时 刻 进 入 了 每 一 个 正 交 区 域 BC 和 BD 中 。 每 一 个 正 交 的 子 状 态 被 进一步 分 
解 为 顺序 的 子 状态 。 因 此 ， 当 进入 组 合 状态 В 时 ， 同 样 进入 了 状态 ВА 和 B3, 
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Initial State 


composite state A 


Substate A1 Event [condition] / 
Action 
entry / Action 


Event / Action 





Final State 


图 2-7 UML 表示 法 中 的 状态 机 : 带 有 顺序 子 状态 的 组 合 状态 











composite state B 






orthogonal region BC 


Event 2 
Substate B1 Substate B2 


orthogonal region BD 
Substate B3 ке Substate В4 


图 2-8 UML 表示 法 中 的 状态 机 : 带 有 正 交 区 域 的 组 合 状态 








Event 4 


Initial State 


27 包 


在 UML 中 ， 包 是 一 组 建 模 元 素 的 组 合 ， 例 如 代表 一 个 系统 或 一 个 子 系统 。 如 图 2-9 所 示 ， 
用 一 个 文件 夹 图 标 表 示 包 ， 即 在 一 个 大 长 方形 的 角 上 依附 一 个 小 长 方形 。 包 也 可 能 被 财 套 在 其 
他 包 里 面 。 依 赖 (dependency, WEI 2-9 中 所 示 ) 和 泛 化 / 特 化 (generalization/specialization ) 是 
包 之 间 可 能 具有 的 关系 。 包 可 用 于 容纳 类 、 对 象 或 者 用 例 。 


«system» 
SystemPackage 


«subsystem» «subsystem» 
Subsystem Subsystem 
PackageA PackageB 





图 2-9 UML 表示 法 中 的 包 
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28 并 发 通信 图 





E UML 表示 法 中 ， 一 个 主动 对 象 可 用 于 描绘 一 个 并 发 对 象 〈concurrent object )、 进 程 
(process )、 线 程 (thread ) 或 任务 (task )。 可 以 用 一 个 左右 两 边 带 有 两 根 垂 直线 的 方 框 表 示 一 
个 主动 对 象 。 主 动 对 象 (active object ) 拥有 自己 的 控制 线程 ， 并 且 能 与 其 他 对 象 并 发 执行 。 与 
此 相反 ， 被 动 对 象 (passive object) 不 具有 控制 线程 。 被 动 对 象 只 在 其 他 对 象 (主动 或 被 动 ) 


调用 其 方法 时 才 会 执行 。 


主动 对 象 在 描绘 系统 并 发 视角 的 并 发 通信 图 中 描绘 ( Douglass 2004 )。 在 UML 2 的 并 发 
通信 图 中 ， 主 动 对 象 用 左右 两 边 带 有 两 条 相互 平行 的 垂直 线 的 矩形 框 表示 ， 被 动 对 象 则 用 常 
规 的 矩形 框 表 示 。 在 UML 1.x 表示 法 中 用 粗 黑 线 矩 形 框 表 示 主 动 对 象 的 方式 已 经 不 再 采用 。 
图 2-10 是 并 发 通信 图 的 一 个 示例 ， 它 也 展示 了 当 同 一 个 类 的 多 个 对 象 被 实例 化 时 对 于 多 对 象 
( multiobject ) 的 表示 法 (在 UML 2 中 不 再 使 用 的 UML 1.x 标记 )。 


Active object 





«active object» 
«passive object» 





Passive object 


П 
Active | «active object» 
multiobject 
Passive 
multiobject «passive object» 





图 2-10 UML 表示 法 中 的 主动 对 象 和 被 动 对 象 


并 发 通信 图 中 的 消息 通信 


并 发 通信 图 中 任务 之 间 的 消息 接口 可 以 是 异步 的 〈 松 耦合 )， 也 可 以 是 同步 的 〈 RA )。 
图 2-11 总 结 了 UML 对 消息 通信 的 表示 法 。 图 2-12 描绘 了 一 个 并 发 通信 图 ， 并 发 通信 图 


«simple message» 
message-name 


简单 消息 > 
a) 消息 类 型 未 确定 


«asynchronous message» 
message-name (argument list) 
——— 


UML 1.3 UML 1.4 il UML 2 
b) 异步 〈 松 耦合 ) 消息 通信 


«synchronous message» 
message-name (argument list) 
— 


с) 同步 〈 紧 耦合 ) 消息 通信 


«synchronous message with reply» 


message-name (in argument list, out argument list) 


一 一 一 一 一 


«synchronous message» 
message-name (argument list) 





«reply» 
< en 
а) 常 回复 的 同步 〈 紧 耦合 ) 消息 通信 


图 2-11 UML 表示 法 中 的 消息 


«asynchronous message» 


g 
еее sine (argument list) 


1: inputMessage 
> «active object» 
objectA 


АВЕ 2: asynchronousMessage № 


«active object» 
objectB 


3: synchronousMessage | 


«active object» 
objectC 


4: synchronousMessage | 


















个 
1 


«active object» 
objectD 


图 2-12 UML 表示 法 中 的 并 发 通信 图 


5: reply 
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是 通信 图 的 一 个 版 本 ， 它 展示 了 主动 对 象 〈《 并 发 对 象 、 进 程 、 任 务 或 线程 ) 以 及 这 些 对 象 之 
间 不 同 种 类 的 消息 通信 。 同 步 的 消息 通信 存在 两 种 可 能 : (1) 带 回复 的 同步 消息 通信 (黑色 
箭头 代表 请 求 ， 带 箭头 的 虚线 代表 回复 ) (2) 不 带 回 复 的 同步 消息 通信 (黑色 箭头 代表 请 
Ж). 需要 注意 ， 从 UML 1.4 开始 ，UML 对 异步 通信 的 表示 从 一 个 半 箭 头 改变 为 一 个 全 箭头 。 
同时 ， 用 全 箭头 表示 一 个 简单 消息 的 方式 是 UML 1.3 与 更 早 版 本 中 的 使 用 惯例 。 在 分 析 建 模 
阶段 ， 当 消息 通信 的 类 型 还 未 确定 时 ， 使 用 简单 消息 是 一 种 有 用 的 方式 。 
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部 署 图 以 物理 结 点 和 结 点 间 物 理 连 接 的 方式 ( 例如 网 络 连接 ) 展示 了 一 个 系统 的 物理 配 
置 。 一 个 结 点 使 用 一 个 立方 体 表 示 ， 连接 则 用 这 些 立 方 体 之 间 的 连接 线 表示 。 本 质 上 ， 部 署 
图 是 以 系统 结 点 为 关注 点 的 一 种 类 图 ((Booch，Rumbaugh，and Jacobson 2005 )。 

本 书 中 ,一 个 结 点 往往 代表 了 一 个 带 有 约束 的 计算 机 结 点 ( 见 2.10.3 节 )， 这 个 约束 描 
述 了 该 结 点 存在 多 少 实例 。 物 理 连接 具有 一 个 表示 连接 类 型 的 构造 型 (stereotype, Jil, 2.10.1 
节 )， 例 如 « 局域网»》( «wide area network» ) 或 «广域网 » («local area network» )。 图 2-13 
展示 了 部 署 图 的 两 个 示例 。 在 第 一 个 示例 中 ， 结 点 通过 广域网 (WAN ) 被 连接 在 一 起 ; 在 第 
二 个 示例 中 ， 结 点 通过 局 域 网 ( LAN ) 连接 在 一 起 。 男 外 ， 在 第 一 个 示例 中 , ATM Client ( 每 
个 ATM 拥有 一 个 结 点 ) 结 点 与 拥有 一 个 结 点 的 Bank Server 连接 。 位 于 结 点 中 的 对 象 可 选择 
性 地 被 表示 在 结 点 立方 体 中 。 在 第 二 个 示例 中 ， 网 络 被 表示 为 一 个 立方 体 结 点 。 当 两 个 以 上 
的 计算 机 结 点 被 同一 网 络 连接 在 一 起 时 ， 可 以 使 用 这 种 表示 形式 。 
| 


ATMClient BankServer 
{1 node per ATM} {1 node} 
el 


«local area network» 












«wide area network» 
























Client1 | Client2 | Client3 | 


Н 2-13 UML 表示 法 中 的 部 署 图 


2.10 UML 扩展 机 制 


UML 提供 了 三 种 语言 扩展 机 制 (Booch，Rumbaugh，and Jacobson 2005 ; Rumbaugh, Booch, 
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and Jacobson 2005 )， 它 们 是 构造 型 (stereotype), #118 (tagged value ) 和 约束 ( constraint )。 
2.10.1 构造 型 


一 个 构造 型 定义 了 一 个 从 已 有 UML 建 模 元 素 中 派生 出 来 的 、 且 针对 建 模 者 问题 进行 裁 
前 的 构造 块 (Booch, Rumbaugh, and Jacobson 2005 )。 本 书 广 泛 使 用 了 构造 型 。UML BA 
义 了 多 种 标准 的 构造 型 。 另 外 ， 建 模 者 可 以 定义 新 的 构造 型 。 本 章 包 括 了 多 个 使 用 构造 型 的 
示例 ， 既 有 标准 构造 型 ， 也 有 COMET 特定 的 构造 型 。 构 造型 是 用 书 名 号 ( «») 表示 的 。 

图 2-9 的 包 图 使 用 构造 型 « 系统 »( system ) 和 《 子 系统 (subsystem ) 来 区 别 这 两 种 不 
同类 型 的 包 。 图 2-11 则 使 用 构造 型 来 区 别 不 同 种 类 的 消息 。 

在 UML1.3 中 ,一 个 UML 建 模 元 素 只 能 具有 一 个 构造 型 。 然 而 ,，UML1.4 及 其 后 的 版 本 
扩展 了 构造 型 的 概念 ， 它 们 允许 一 个 建 模 元 素 被 附加 多 个 构造 型 。 因 此 ， 一 个 建 模 元 素 不 同 
的 、 可 能 正 交 的 特性 可 以 通过 不 同 的 构造 型 被 描绘 出 来 。COMET 方法 就 是 利用 了 这 个 附加 
的 功能 。 

UML 构造 型 表示 法 允许 一 个 建 模 者 针对 一 个 特定 的 问题 对 UML 建 模 元 素 进行 裁剪 。 如 
2-14а 所 示 ，UML 的 构造 型 一 般 位 于 建 模 元 素 ( 例如 类 或 对 象 ) 内 部 ， 并 且 使 用 书 名 号 标 
记 。 然 而 ，UML 也 允许 将 构造 型 表示 为 符号 。 其 中 一 个 最 通常 的 表示 方式 是 Jacobson 提出 
的 ， 它 用 于 统一 软件 开发 过 程 (Unified Software Development Process, USDP ) 中 ( Jacobson, 
Booch, and Rumbaugh 1999 )。 该 过 程 使 用 构造 型 表示 « 实体 »( entity ) 类 、« 边界 »( boundary ) 
类 和 «控制 >》(control) 类 。 图 2-14b 展示 了 使 用 USDP 的 构造 型 符号 所 表示 的 Process 
Plank 实体 XÆ., Elevator Control« 控制 》 类 以 及 Sensor Interface« 边界 » 类 。 


«entity» «control» «boundary» 
ProcessPlan ElevatorControl Sensorinterface 


а) 标准 UML 表 示 法 中 使 用 的 构造 型 


O © ый 


ProcessPlan ElevatorControl Sensorinterface 
b) 统一 软件 开发 过 程 中 使 用 的 构造 型 
图 2-14 UML 构造 型 的 可 选择 的 表示 法 
2.10.2 标记 值 


标记 值 扩 展 了 一 个 UML 构造 块 的 属性 (Booch, Rumbaugh, and Jacobson 2005 )， 从 而 


为 其 增加 新 的 信息 。 标 记 值 以 { 标记 = 值 } 的 形式 书写 
«entity» 


在 大 括号 中 。 新 添加 的 标记 值 用 逗号 分 隔 。 如 图 2-15 

所 示 ， 一 个 类 可 具有 标记 值 { 版 本 =1.0， 作 者 =Gill} 。 
-accountNumber : integer 
-balance : real {balance >= 0} 


2.10.3 AR 


约束 指定 了 一 个 必须 为 真 的 条 件 。 在 UML 中 , CS UME ЧАРЧОО 
约束 是 一 个 UML 元 素 语义 的 扩展 ， 它 允许 新 规则 的 加 入 或 修改 已 存在 的 规则 (Booch, 
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Rumbaugh, and Jacobson 2005). 4n 2-15 中 的 Account Ж 7Е Ж Је PE balance 上 具有 约束 
{balance>=0} ， 表 示 账 户 的 余额 不 能 为 负数 。 另 外 ，UML 也 提供 了 对 象 约束 语言 (Object 
Constraint Language, Warmer and Kleppe 1999) 来 表达 约束 。 


2.11 本 书 的 约定 


本 书 用 到 的 一 些 特定 的 附加 约定 随 着 项 目的 阶段 而 改变 。 例 如 ， 大 小 写 约定 在 分 析 模 型 
(ARER) 和 设计 模型 ( 更 为 正式 ) 中 是 不 同 的 。 


2.11.1 需求 建 模 


在 图 和 文本 中 ， 用 例 的 名 字 采 用 单词 的 首 字母 大 写 的 形式 ， 且 在 多 个 单词 中 使 用 空格 ， 
例如 Withdraw Funds。 


2.11.2 分析 建 模 


分 析 模 型 的 命名 约定 如 下 : 

1. 类 

类 名 单词 首 字 母 大 写 。 在 图 中 ， 多 单词 的 名 字 间 没有 空格 ， 例 如 CheckingAccount。 然 而 
在 文本 中 ， 为 了 提升 可 读 性 引入 了 空格 ， 例 如 Checking Account. 

属性 名 单词 首 字 母 小 写 ， 例 如 balance。 对 于 多 单词 组 成 的 属性 ， 在 图 中 不 使 用 空格 分 
隔 ， 但 在 文本 中 引信 空 格 。 多 单词 名 称 中 的 第 一 个 单词 首 字 母 小 写 ， 接 下 来 的 单词 首 字 母 大 
写 。 例 如 ， 在 图 中 使 用 accountNumber， 在 文本 中 使 用 account Number. 

属性 的 类 型 使 用 首 字母 大 写 的 单词 表示 ， 例 如 Boolean, Integer 或 Real, 

2. 对 象 

对 象 可 以 通过 多 种 方式 表示 ， 如 下 所 述 : 

• 一 个 单独 的 命名 对 象 。 在 这 种 情况 下 ， 第 一 个 单词 的 首 字 母 小 写 ， 之 后 单词 的 首 字 母 
大 写 。 例 如 ， 在 图 中 ， 对 象 表示 为 aCheckingAccount 和 anotherCheckingAccount 的 形 
式 ; 在 文本 中 ， 相 同 的 对 象 表示 为 aChecking Account 和 another CheckingAccount 的 
形式 。 
一 个 单独 的 未 命名 对 象 。 图 中 有 些 对 象 被 表示 为 不 具有 对 象 名 的 类 实例 ， 例 如 : 
CheckingAccount。 在 文本 中 ， 这 个 对 象 被 命名 为 CheckingAccount。 为 了 提升 可 读 性 ， 
冒号 被 去 除了 ， 且 在 多 单词 组 成 的 名 字 中 引入 了 空格 。 

这 意味 着 ， 根 据 一 个 对 象 在 图 中 的 表示 方式 ， 在 文本 中 有 时 该 对 象 的 首 单词 首 字 母 大 写 ， 
有 时 首 单词 的 首 字母 小 写 。 

3. 消息 

在 分 析 模 型 中 ， 由 于 消息 的 类 型 未 被 确定 ， 因 此 消息 总 是 表示 为 简单 消息 (参见 图 2-11 
和 2.8.1 节 )。 消 息 名 字 的 首 字母 大 写 。 在 图 和 文本 中 ， 多 单词 组 成 的 消息 名 字 具 有 空格 ， 例 
如 Simple Message Name。 

4. 状态 图 

在 图 和 文本 中 ， 状 态 、 事 件 、 条 件 、 动 作 和 活动 的 名 称 都 是 首 字 母 大 写 的 ， 并 且 在 多 单 
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词 间 存在 空格 ， 例 如 ， 状 态 Waiting for PIN, #4: Cash Dispensed, /F Dispense Cash. 
2.11.3 ”设计 建 模 


设计 模型 的 命名 约定 如 下 : 

1. 主动 类 和 被 动 类 

主动 类 ( 并 发 类 ) 和 被 动 类 的 命名 约定 与 分 析 模 型 中 类 的 命名 约定 一 致 ( 见 2.11.2 节 )。 

2. 主动 对 象 和 被 动 对 象 

主动 对 象 (并 发 对 象 ) 和 被 动 对 象 的 命名 约定 与 分 析 模 型 中 对 象 的 命名 约定 一 致 ( 见 
2.11.2 73 )ь 

3. 消息 

在 设计 模型 中 ， 消 息 名 字 的 第 一 个 单词 首 字 母 是 小 写 的 ， 接 下 来 的 单词 首 字 母 大 写 。 在 
图 和 文本 中 ， 单 词 之 间 都 没有 空格 ， 如 alarmMessage。 

消息 参数 的 名 字 用 首 字母 小 写 的 形式 ， 例 如 speed。 在 图 和 文本 中 ， 多 单词 的 属性 名 字 
之 间 没 有 空格 ， 另 外 ， 多 单词 名 字 的 第 一 个 单词 首 字 母 小 写 ， 之 后 的 单词 首 字 母 大写 ， 例 如 


cumulativeDistance。 

4. 操作 

在 图 和 文本 中 ， 操 作 〈 也 叫 方法 ) 的 命名 约定 都 遵循 消息 的 命名 约定 。 因 此 ， 操 作 及 其 
参数 的 第 一 个 单词 的 首 字 母 都 是 小 写 的 ， 之 后 的 单词 首 字母 大 写 。 单 词 之 间 不 存在 空格 ， 例 


如 validatePassword ( userPassword )。 
212 总结 


本 章 简要 介绍 了 UML 表示 法 的 主要 特征 和 本 书 中 使 用 的 UML 图 的 主要 特性 。 

为 进一步 阅读 关于 UML 2 表示 法 的 内 容 ，Fowler (2004) 和 Ambler (2005) 提供 了 介 
绍 性 的 材料 。 更 多 的 详细 信息 可 在 Booch，Rumbaugh，and Jacobson ( 2005 ) 和 Eriksson et 
al. (2004) 中 找到 。 其 中 ，Rumbaugh，Booch，and Jacobson (2005) 提供 了 对 UML 的 广泛 
而 详细 的 参考 。 


练习 


选择 题 ( 每 道 题 选择 一 个 答案 ) 
1. 在 用 例 图 中 ， 参 与 者 如 何 表示 ? 


(a) Ж (b) 人 形 图 标 
(с) 方 杠 (d ) 虚线 

2. 在 用 例 图 中 ， 用 例如 何 表 示 ? 
(а) Ж ЇЙ] (b) 人 形 图 标 
(с) УЖЕ (d) 虚线 


3. 在 类 图 中 ， 类 如 何 表示 ? 
(а) 具有 一 个 分 隔 区 域 的 方 杠 
(b) 具有 一 个 或 两 个 分 隔 区 域 的 方 杠 
(с) 具有 一 个 、 两 个 或 三 个 分 隔 区 域 的 方 杠 
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(а) Al 

4. 在 类 图 中 ， 关 联 如 何 表示 ? 

Ca) 两 个 类 方 框 之 间 的 实 线 (b) 两 个 类 方 框 之 间 的 虚线 
(с) 一 个 接触 上 层 类 方 框 的 菱形 (а) 一 个 接触 上 层 类 方 框 的 箭头 
5. 在 类 图 中 ， 类 元 素 的 公有 可 见 性 如 何 表示 ? 


(a) + 号 (b) -号 

(с) # 号 (d)* 号 

6. UML 交互 图 有 哪 两 种 类 型 ? 

(a) 类 图 和 顺序 图 (b) 顺序 图 和 通信 图 
(c) 类 图 和 通信 图 (d) 状态 图 和 通信 图 
7. 交互 图 用 来 描绘 什么 ? 

(а) 对 象 和 连接 (b) 类 和 关系 

(с) 对 象 和 消息 (d) 状态 和 事件 

8. 状态 图 用 来 描绘 什么 ? 

(а) 对 象 和 连接 (b) 类 和 关系 

(с) 对 象 和 消息 ( а) 状态 和 事件 
9. UML 包 是 什么 ? 

(а) 一 个 方 框 (b) 一 组 类 的 聚集 
(с) 一 组 用 例 的 聚集 (d) 一 组 模型 元 素 的 聚集 


10. 部 署 图 用 来 描绘 什么 ? 
(a) 以 物理 类 和 类 间 物 理 连 接 的 方式 描绘 系统 的 物理 配置 
(b) 以 物理 对 象 和 对 象 间 物理 连接 的 方式 描绘 系统 的 物理 配置 
(с) 以 物理 结 点 和 结 点 间 物 理 连接 的 方式 描绘 系统 的 物理 配置 
(4) 以 物理 计算 机 和 计算 机 间 物 理 网 络 的 方式 描绘 系统 的 物理 配置 
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软件 生存 周期 模型 和 过 程 





软件 生存 周期 是 以 开发 软件 为 目的 的 一 种 分 阶段 方法 ， 在 每 一 阶段 都 有 特定 的 交付 物 和 
里 程 碑 。 软 件 生存 周期 模型 是 软件 开发 过 程 的 抽象 ， 它 能 简便 地 用 于 规划 软件 开发 的 整体 过 
程 。 本 章 从 软件 生存 周期 的 视角 来 讲述 软件 开发 ， 其 中 简要 描述 和 对 比 了 不 同 种 类 的 软件 生 
存 周期 模型 ( 也 称 为 软件 过 程 模型 )， 这 些 模型 包括 螺旋 模型 和 统一 软件 开发 过 程 。 另 外 ,本 
章 也 讨论 了 设计 验证 和 确认 以 及 软件 测试 这 几 项 工作 所 承担 的 角色 。 


3.1 软件 生存 周期 模型 


瀑布 模型 ( waterfall model ) 是 最 早 被 广泛 使 用 的 软件 生存 周期 模型 。 本 节 首 先 回顾 瀑布 
模型 ,然后 概述 其 他 可 选择 的 软件 生存 周期 模型 ， 这 些 模 型 用 来 克服 瀑布 模型 的 部 分 局 限 性 ， 
它们 是 : 抛弃 型 原型 生存 周期 模型 ( throwaway prototyping life cycle model )， 增 量 开 发 生存 周 
期 模型 ( incremental development life cycle model， 也 称 为 演化 式 原型 evolutionary prototyping ), 
螺旋 模型 ( spiral model )， 以 及 统一 软件 开发 过 程 ( Unified Software Development Process )。 


3.1.1 瀑布 生存 周期 模型 


从 20 世纪 60 年 代 以 来 ， 开 发 软件 的 成 本 逐步 增长 ， 同 时 制造 和 购买 硬件 的 成 本 则 急剧 
下 降 。 进 一 步 说 ， 当 前 软件 成 本 一 般 占 据 整 个 项 目 预算 的 百 分 之 八 十 ， 然 而 在 软件 开发 的 早 
期 ， 硬 件 则 是 最 大 的 项 目 成 本 (Boehm 2006 )。 

在 20 世纪 60 年 代 ， 相 关 人 员 还 没有 明确 理解 与 开发 软件 相关 的 一 些 问题 。 在 60 年 代 
后 期 ， 人 们 才 理 解 到 存在 软件 危机 这 一 问题 。 软 件 工程 这 个 术语 是 指 为 了 有 效 开 发 一 个 大 型 
软件 系统 所 需要 的 管理 与 技术 方法 、 过 程 和 工具 。 随 着 软件 工程 概念 的 不 断 推广 与 使 用 ， 人 
们 已 经 使 用 软件 生存 周期 模型 开发 了 许多 大 规模 的 软件 。 图 3-1 展示 了 第 一 个 被 广泛 使 用 的 
软件 生存 周期 模型 ， 通 常 指 的 是 瀑布 模型 ， 它 一 般 被 看 做 是 传统 的 或 者 “古典 ”的 软件 生存 
周期 。 瀑 布 模型 是 一 个 理想 化 的 过 程 模型 ， 它 规定 每 一 阶段 完成 后 才能 启动 下 一 阶段 ， 另 外 ， 
一 个 项 目 在 没有 迭代 和 重复 的 情况 下 从 一 个 阶段 移动 到 下 一 个 阶段 。 


3.1.2 ”瀑布 模型 的 局 限 性 


瀑布 模型 是 对 早期 软件 项 目 所 使 用 的 较为 散乱 的 开发 方法 的 一 种 重要 改进 ， 它 已 经 被 成 
功 应 用 在 许多 项 目 中 。 然 而 ， 事 实 上 ， 当 在 开发 中 检测 到 一 些 软件 错误 时 ， 在 生存 周期 的 连 
续 阶 段 中 时 常 需要 一 些 重复 与 迭代 〈 见 图 3-2 )。 此 外 ， 对 于 一 些 软件 开发 项 目 而 言 ， 瀑 布 模 
型 会 呈现 出 以 下 显著 问题 : 

® 软件 需求 作为 软件 开发 项 目 中 的 一 个 关键 因素 ， 无 法 进行 合适 的 测试 ， 直 至 一 个 工作 
系统 被 开发 出 来 并 能 演示 给 最 终 用 户 。 事 实 上 ， 好 几 个 研究 工作 已 经 指出 软件 需求 规 
约 的 错误 通常 在 最 后 才 被 检测 到 ( 直至 执行 系统 测试 或 验收 测试 才能 被 检测 到 )， 并 
且 需 要 花费 最 大 的 代价 对 其 进行 纠正 。 
只 有 在 生存 周期 的 后 期 才能 得 到 一 个 工作 的 系统 。 因 此 ， 直 到 系统 几乎 可 以 运行 时 ， 
一 个 重要 的 设计 或 性 能 问题 才 有 可 能 被 发 现 ， 到 那 时 通常 已 经 太 晚 了 ， 以 至 于 无 法 采 
取 有 效 的 措施 。 
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对 于 带 有 很 大 风险 因素 的 软件 开发 项 目 来 说 一 一 例如 ， 由 于 那些 无 法 清晰 理解 或 预期 会 
改变 的 需求 所 导致 的 风险 一 一 瀑布 模型 的 变 体 或 者 其 他 替代 模型 已 经 被 提出 。 

可 以 使 用 两 种 不 同 的 软件 原型 方法 来 克服 瀑布 模型 的 一 些 局 限 : 抛弃 型 原型 和 演化 式 原 
型 。 抛 弃 型 原型 有 助 于 解决 瀑布 模型 的 第 一 个 问题 ， 这 个 问题 在 前 面 的 列表 中 已 被 描述 ， 演 
化 式 原型 则 有 助 于 解决 第 二 个 问题 。 


3.1.3 ”抛弃 型 原型 


抛弃 型 原型 有 助 于 阐明 用 户 需求 。 该 方法 对 从 用 户 界面 上 获得 反馈 非常 有 用 ， 并 且 能 够 
应 用 于 具有 复杂 用 户 界面 的 系统 。 

一 个 抛弃 型 原型 能 够 在 一 个 初步 的 需求 规约 被 制定 之 后 就 被 开发 出 来 (图 3-3 )。 通 过 让 
用 户 使 用 原型 ， 可 以 得 到 许多 通常 难以 得 到 的 有 价值 的 反馈 。 以 这 些 反馈 为 基础 ， 就 可 以 准 
备 制定 一 个 修订 的 需求 规约 。 后 续 的 开发 过 程 则 延续 了 传统 的 软件 生存 周期 。 

针对 详 述 交互 式 信息 系统 需求 的 问题 ， 抛 弃 型 原型 ( 尤其 是 用 户 界面 的 原型 ) 已 经 成 为 
解决 该 问题 的 一 种 有 效 方案 。Gomaa ( 1990 ) 描述 了 如 何 使 用 抛弃 型 原型 来 阐明 一 个 具有 高 
度 交 互 性 的 制造 型 应 用 软件 的 需求 。 该 原型 有 助 于 克服 存在 于 用 户 和 开发 者 之 间 的 沟通 障碍 
这 一 最 大 的 问题 。 

抛弃 型 原型 也 能 被 用 于 构造 设计 的 实验 性 原型 ( 图 3-4 )。 这 个 原型 能 用 于 确定 特定 的 算 
法 是 否 逻 辑 正 确 ， 或 者 用 于 确定 它们 是 否 满足 性 能 目标 。 


3.1.4 通过 增 量 开发 的 演化 式 原型 


演化 式 原 型 方法 是 增 量 开发 的 一 种 形式 ， 在 增 量 开发 中 ， 原 型 从 几 个 中 间 步 又 的 可 运行 
系统 (图 3-5 ) 逐步 演化 为 可 交付 系统 。 该 方法 可 用 于 确定 系统 是 否 满足 性 能 目标 ， 并 用 于 测 
试 设计 中 所 涵盖 的 关键 构件 。 另 外 ， 通 过 将 实现 分 布 在 一 个 较 长 的 时 间 段 内 也 降低 了 开发 的 
风险 。 用 例 和 基于 场景 的 通信 图 能 辅助 选择 每 一 次 增 量 中 的 系统 子 集 。 

演化 式 原 型 方法 的 一 个 目标 是 得 到 早期 运行 的 系统 子 集 ， 随 后 在 该 子 集 上 逐步 构造 。 如 
果 系 统 的 第 一 个 增 量 版 本 对 一 条 从 外 部 输入 到 外 部 输出 的 路 径 进行 了 完整 的 测试 ， 那 么 使 用 
增 量 式 原 型 方式 是 有 优势 的 。 

Gomaa (1990 ) 描述 了 通过 增 量 开发 的 演化 式 原型 的 一 个 实例 。 开 发 者 在 一 个 实时 的 机 
器 人 控制 系统 (Gomaa 1986) 中 使 用 了 这 种 方法 ， 结 果 得 到 了 一 个 系统 的 早期 可 运行 版 本 ， 
这 极 大 鼓舞 了 开发 团队 和 管理 者 的 士气 。 同 时 ， 这 种 方法 也 带 来 了 一 系列 的 好 处 ， 包 括 验证 
系统 的 设计 、 确 定 特定 的 关键 算法 是 否 满足 性 能 目标 以 及 持续 进行 系统 集成 。 


315 抛弃 型 原型 和 增 量 开发 的 结合 


与 传统 的 瀑布 生存 周期 相 比 ， 使 用 增 量 开发 的 生存 周期 模型 方法 能 够 更 早 地 得 到 一 个 以 
演化 式 原 型 为 形式 的 工作 系统 。 然 而 ， 开 发 这 种 类 型 的 原型 比 开 发 一 个 抛弃 型 原型 需要 投入 
更 多 的 关注 ， 这 是 由 于 演化 式 原型 形成 了 最 终 产品 的 基础 ; 因此 ， 从 一 开始 就 必须 将 软件 质 
量 考虑 进来 ， 而 不 能 将 其 作为 一 种 事后 产物 添加 进来 。 特 别 是 ， 需 要 仔细 地 设计 软件 体系 结 
构 并 且 指明 所 有 的 接口 。 

传统 的 瀑布 生存 周期 模型 因 引 人 抛弃 型 原型 或 增 量 开发 而 受到 严重 的 冲击 。 将 抛弃 型 原 
型 与 增 量 开发 这 两 种 方法 结合 起 来 也 是 有 可 能 的 ， 如 图 3-6 所 示 。 其 中 ， 抛 弃 型 原型 被 用 来 
阐明 需求 。 当 理解 需求 并 完成 规约 之 后 ， 就 可 开始 进行 一 个 增 量 开 发 生存 周期 。 在 后 续 的 增 
量 开 发 中 ， 由 于 用 户 环境 的 变化 ,需求 的 进一步 变更 也 可 能 是 必要 的 。 
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3.1.6 ”螺旋 模型 
32 


螺旋 模型 是 一 个 风险 驱动 的 过 程 模型 ， 最 初 由 Boehm (1988) 开发 用 来 解决 软件 生存 周 | ， 
期 早期 过 程 模型 中 存在 的 已 知 问题 ， 尤 其 是 瀑布 模型 中 的 问题 。 螺 旋 模 型 旨 在 涵盖 其 他 生存 137 
周期 模型 ， 例 如 瀑布 模型 、 增 量 开发 模型 以 及 抛弃 型 原型 模型 。 

在 螺旋 模型 中 ， 径 向 坐标 代表 成 本 ， 角 坐标 代表 完成 一 次 模型 周期 ( 循环 ) 的 成 果 。 螺 
旋 模 型 包含 以 下 4 个 象限 ， 如 图 3-7 所 示 。 


1. 定 义 目标 、 候 选 方法 和 约束 2. 分 析 风 险 


3. 开 发 产品 4. 计 划 下 一 次 循环 





图 3-7 ”螺旋 过 程 模型 


1) 定义 目标 、 候 选 方法 和 约束 。 此 次 循环 的 详细 计划 : 确定 目标 以 及 用 来 实现 目标 的 各 
种 候选 方法 。 

2) 分 析 风 险 。 对 当前 项 目 风险 进行 详细 评估 ; 为 了 减轻 风险 ， 计 划 待 执行 的 活动 。 

3 ) 开发 产品 。 进 行 产品 开发 ， 例 如 需求 分 析 、 设 计 或 者 编码 。 

4) 计划 下 一 次 循环 。 对 此 次 循环 的 成 果 进 行 评估 ， 并 开始 计划 下 一 次 循环 。 

螺旋 模型 的 每 一 次 循环 都 会 迭代 地 经 过 这 4 个 象限 ， 尽 管 循 环 的 次 数 是 由 特定 项 目 决定 
的 。 每 一 个 象限 中 的 活动 描述 都 要 足够 通用 ， 使 得 它们 能 够 被 包含 在 任何 一 个 循环 中 。 

螺旋 模型 的 目标 是 风险 驱动 ， 因 此 一 个 特定 循环 中 的 风险 由 “分 析 风 险 ” 这 一 象限 决定 。 
为 了 管理 这 些 风 险 ， 需 要 额外 地 计划 特定 项 目的 活动 来 解决 这 些 风 险 。 例 如 ， 当 风险 分 析 指 
出 软件 需求 并 未 被 清晰 理解 时 ， 就 需要 采用 需求 原型 。 这 些 特定 项 目的 风险 被 称 为 过 程 驱 动 
A (process driver )。 对 于 任何 过 程 驱动 力 而 言 ， 需 要 执行 一 个 或 多 个 特定 项 目的 活动 来 管理 
这 个 风险 (Boehm and Belz 1990 )。 

识别 一 个 特定 项 目 风 险 的 例子 是 确定 初始 的 软件 需求 没有 被 很 好 地 理解 。 用 来 管理 该 风 
险 所 需 执 行 的 一 个 特定 项 目的 活动 是 开发 一 个 抛弃 型 原型 ， 其 目的 是 从 用 户 处 得 到 反馈 从 而 
有 助 于 阐明 系统 的 需求 。 


3.17 ”统一 软件 开发 过 程 


按照 Jacobson et al. (1999) 中 的 描述 ， 统 一 软件 开发 过 程 ( USDP ) 是 使 用 UML 表示 法 
的 一 种 用 例 驱 动 的 软件 过 程 。USDP 也 被 称 为 Rational 统一 过 程 (RUP ) ( Kroll and Kruchten 
2003 ; Kruchten 2003 ). USDP/RUP 是 一 种 流行 的 基于 UML 的 软件 开发 过 程 。 本 节 介 绍 
PLUS 方法 如 何 用 于 USDP/RUP 过 程 。 
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如 图 3-8 Pras, USDP 包含 5 个 核心 工作 流 和 4 个 阶段 ， 同 时 USDP 是 可 迭代 的 。 制 品 
(artifact) 被 定义 为 由 一 个 过 程 生产 、 修 改 或 使 用 的 信息 (Kruchten 2003 )。 工 作 流 ( workflow ) 
被 定义 为 生产 可 观测 结果 的 一 系列 活动 (Kruchtem 2003 )。 阶 段 (phase ) 被 定义 为 两 个 里 程 碑 
之 间 的 一 段 时 间 ， 在 此 过 程 中 一 组 事先 定义 的 开发 目标 得 到 了 满足 ， 完 成 了 一 些 制品 ， 同 时 
做 出 了 是 否 进入 下 一 阶段 的 决定 (Kruchten 2003 )。 通 常 ， 在 一 个 阶段 中 存在 超过 一 次 的 迭代 ; 
因此 ，USDP 中 一 个 阶段 迭代 与 螺旋 模型 中 的 一 次 循环 是 相对 应 的 。 


阶段 





核心 工作 流 







| iteration 
#n-1 





| 
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1 
1. > 
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1 fn 





迭代 
图 3-8 ”统一 软件 开发 过 程 (Jacobson et al, THE UNIFIED SOFTWARE DEVELOPMENT PROCESS, 
Figure 1.5 “Unified Software Development Process” p.11, ©1999 Pearson Education, Inc. 


Reproduced by permission of Pearson Education, Inc. ) 


每 一 次 循环 历经 所 有 的 四 个 阶段 ， 并 且 指 明了 每 一 个 核心 工作 流 中 的 开发 工作 。 每 一 个 
工作 流 及 其 产物 如 下 所 述 : 

1 ) 需求 。 需 求 工 作 流 的 产物 是 用 例 模型 。 

2 ) 分 析 。 分 析 工 作 流 的 产物 是 分 析 模 型 。 

3 ) 设计 。 设 计 工 作 流 的 产物 是 设计 模型 和 部 署 模型 。 

4) 实现 。 实 现 工作 流 的 产物 是 实现 模型 。 

5) 测试 。 测 试 工 作 流 的 产物 是 测试 模型 。 

与 螺旋 模型 类 似 ，USDP 是 一 个 风险 驱动 的 过 程 。USDP 生存 周期 阶段 如 下 所 述 
(Jacobson, Booch, and Rumbaugh 1990; Kruchten 2003 ): 

1) 初始 。 在 初始 阶段 ， 制 定 出 达到 足够 水 平 的 初步 想法 ， 用 以 证 明 有 能 力 进 入 细 化 阶段 。 

2 ) 细 化 。 在 细 化 阶段 ， 定 义 软件 体系 结构 。 

3) 构造 。 在 构造 阶段 ， 开 发 出 能 够 发 布 给 用 户 的 软件 产品 。 

4) 交付 。 在 交付 阶段 ， 软 件 被 交付 给 用 户 。 


3.2 设计 验证 和 确认 


Boehm ( 1981) 区 分 了 软件 确认 (software validation ) 和 软件 验证 ( software verification )。 
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软件 确认 的 目标 是 要 确保 软件 开发 团队 “构建 了 正确 的 系统 ”， 也 就 是 说 ， 确 保 系 统 符合 用 户 
的 需求 。 软 件 验 证 的 目标 是 要 确保 软件 开发 团队 “正确 地 构建 系统 ”， 也 就 是 说 ， 确 保 软件 系 
统 在 每 一 个 阶段 中 的 构造 与 前 一 个 阶段 所 定义 的 规约 相符 合 。 

本 节 简 要 讨论 的 主题 是 软件 质量 保证 (software quality assurance ) 和 软件 设计 的 性 能 分 
析 ( performance analysis of software designs )。 男 一 个 重要 的 活动 是 根据 软件 需求 测试 整个 集 
成 系统 ， 它 是 在 系统 测试 阶段 实施 的 ， 这 部 分 内 容 将 在 软件 测试 的 3.3 节 中 进行 介绍 。 


3.2.1 软件 质量 保证 


软件 质量 保证 是 指 一 系列 确保 软件 产品 质量 的 活动 。 软 件 验 证 和 确认 是 软件 质量 保证 的 
重要 目标 。 

根据 用 户 需 求 ， 抛 弃 型 原型 能 够 用 于 对 系统 的 确认 (在 开发 系统 之 前 )， 有 助 于 确保 开发 
团队 “构建 了 正确 的 系统 ”， 即 系统 确实 符合 用 户 的 需求 。 抛 弃 型 原型 也 能 够 用 于 构造 设计 的 

软件 技术 评审 ( software technical review ) 能 够 为 软件 验证 和 确认 带 来 很 大 的 帮助 。 在 软 
件 验 证 中 ， 确 保 设 计 符合 软件 需求 规约 是 非常 重要 的 。 需 求 追踪 和 软件 设计 的 技术 评审 能 够 
有 助 于 该 活动 的 开展 。 


3.2.2 ”软件 设计 的 性 能 分 析 


在 系统 实现 之 前 分 析 软 件 设 计 的 性 能 来 评估 设计 是 否 满足 性 能 目标 是 十 分 有 必要 的 。 如 
果 在 生存 周期 早期 就 能 发 现 潜在 的 性 能 问题 ， 那 么 就 能 够 采取 措施 来 克服 它们 。 

评估 软件 设计 的 方法 使 用 排队 模型 ( Meenascé, Almeid, and Dowdy 2004 ; Menascé, 
Gomaa, and Kerschberg 1995; Menascé and Сотта 2000 ) 和 模拟 模型 ( Smith 1990 )。 对 于 并 
行 系统 而 言 ， 能 够 使 用 Petri 网 (David 1994 ; Jensen 1997 ; Pettit and Gomaa 2006 ; Stansifer 
1994) 来 建 模 和 分 析 并 行 设计 。 在 ( Gomaa 2000) 中 描述 的 一 个 方法 是 通过 使 用 实时 调度 理 
论 来 分 析 实 时 设计 的 性 能 。 


3.3 软件 生存 周期 的 活动 
无 论 采用 哪 种 软件 生存 周期 ， 都 需要 执行 以 下 章节 所 简要 描述 的 软件 工程 活动 。 
331 需求 分 析 和 规约 


在 这 个 阶段 ， 识 别 和 分 析 用 户 的 需求 。 软 件 需 求 规约 ( SRS ) 详细 人 氢 述 了 需要 开发 出 
的 系统 的 需求 。SRS 是 软件 的 一 类 外 部 规约 ， 它 的 目的 是 提供 完整 的 关于 系统 外 部 行为 是 
什么 的 描述 ， 而 不 描述 系统 内 部 是 如 何 进行 工作 的 。Davis ( 1993 ) 清晰 地 描述 了 SRS 的 构成 。 

在 诸如 能 人 式 系 统 这 样 的 系统 中 ， 软 件 是 更 大 范围 的 硬件 /软件 系统 的 一 个 组 成 部 分 ， 
系统 的 需求 分 析 和 规约 阶段 就 有 可 能 在 软件 需求 的 分 析 和 规约 之 前 进行 。 使 用 这 种 方法 ,在 
软件 需求 分 析 开 始 之 前 ， 系 统 功能 性 需求 就 被 分 配 到 软件 和 硬件 上 了 。 


3.3.2 ”体系 结构 设计 


一 个 软件 体系 结构 (Bass, Clements, and Kazman 2003 ; Shaw and Garlan 1996 ) ЯН 
述 构件 及 其 连接 的 方式 ， 将 系统 的 整体 结构 与 单个 构件 的 内 部 实现 细节 进行 分 离 。 重 点 是 对 
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构件 及 其 连接 的 描述 ， 有 时 被 称 为 大 规模 编程 (programming-in-the-large )， 而 单个 构件 的 详 
细 设 计 则 被 称 为 小 规模 编程 (programming-in-the-small )。 在 这 个 阶段 中 ， 构 件 组 成 了 系统 的 
结构 ， 同 时 定义 了 这 些 构 件 之 间 的 接口 。 


3.3.3 详细 设计 


在 详细 设计 阶段 ， 定 义 每 一 个 系统 构件 的 算法 细节 。 这 项 工作 经 常 使 用 程序 设计 
语言 (PDL ) 来 完成 ， 这 种 语言 也 被 称 为 结构 化 英语 (Structured English) 或 者 伪 代 码 
(pseudocode )。 另 外 ， 内 部 数据 结构 也 会 被 设计 。 


3.3.4 те 


在 编码 阶段 ， 使 用 为 这 个 项 目 所 选择 的 编程 语言 对 每 一 个 构件 进行 编码 。 通 常 这 项 工作 
要 遵循 一 系列 的 编码 和 文档 标准 。 


34 软件 测试 


由 于 发 现 错误 以 及 定位 和 纠正 错误 的 困难 性 ， 因 此 在 多 个 阶段 都 要 进行 软件 测试 
(Ammann and Offutt 2008 )。 单 元 测试 和 集成 测试 是 “ 白 盒 ”测试 方法 ， 需 要 了 解 软件 的 内 部 
ЯНА; 系统 测试 是 基于 软件 需求 规约 的 “ 黑 盒 ”测试 方法 ， 不 需要 了 解 软件 内 部 结构 。 


3.4.1 单元 测试 


单元 测试 表示 在 单个 构件 与 其 他 构件 进行 组 合 之 前 对 其 进行 单独 的 测试 。 单 元 测试 的 方 
法 使 用 测试 覆盖 准则 ， 经 常 使 用 的 测试 覆盖 准则 包括 语句 覆盖 (statement coverage) 和 分 支 
# & (branch coverage )。 语 句 覆盖 需要 达到 每 一 个 语句 应 至 少 被 执行 一 次 。 分 支 覆 盖 则 需要 
达到 每 一 个 分 支 的 可 能 结果 应 至 少 被 测试 一 次 。 


3.4.2 ”集成 测试 


集成 测试 表示 将 已 测试 的 单个 构件 逐步 地 组 合 为 更 复杂 的 构件 组 ， 然 后 对 这 些 构件 组 进 
行 测试 ， 直 到 组 合成 完整 的 软件 系统 ， 同 时 构件 间 的 接口 都 已 经 被 测试 过 。 


343 ”系统 测试 


系统 测试 是 测试 一 个 经 过 集成 的 硬件 和 软件 系统 来 验证 系统 是 否 满足 特定 需求 的 一 个 过 
fÈ (IEEE 1990 )。 测 试 人 员 测 试 整个 系统 或 主要 的 子 系统 来 判定 它们 是 否 与 需求 规约 保持 一 
致 。 为 了 使 测试 更 加 客观 ， 推 荐 让 一 个 独立 的 测试 团队 来 执行 系统 测试 。 

在 系统 测试 过 程 中 ,需要 测试 软件 系统 的 几 个 特征 ( Beizer 1995 )。 这 些 特征 包括 : 

o 功能 测试 。 判 定 系统 执行 了 需求 规约 中 所 描述 的 功能 。 

e 负载 ( 压力 ) 测试 。 判 定 当 系统 运行 时 是 否 能 够 处 理 计划 中 的 大 量 的 和 变化 的 负载 。 

o 性 能 测试 。 测 试 系统 满足 响应 时 间 的 需求 。 


3.4.4 ”验收 测试 


在 验收 系统 之 前 ,通常 在 用 户 安装 阶段 ， 用 户 组 织 或 其 代表 都 会 进行 验收 测试 。 与 系统 
测试 相关 的 大 多 数 问题 也 应 用 于 验收 测试 。 
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35 BE 


本 章 从 软件 生存 周期 的 视角 讲述 软件 开发 ， 其 中 简要 描述 和 对 比 了 不 同 种 类 的 软件 生存 
周期 模型 ， 也 被 称 为 软件 过 程 模 型 ( 包括 螺旋 模型 和 统一 软件 开发 过 程 )。 男 外 ， 本 章 还 讨论 
了 设计 验证 和 确认 以 及 软件 测试 这 几 项 工作 所 承担 的 角色 。 第 5 章 将 介绍 COMET 方法 的 基 


于 用 例 的 软件 生存 周期 。 
练习 


选择 题 ( 每 道 题 选择 一 个 答案 ) 
1. 什么 是 软件 生存 周期 ? 

(а) 软件 的 生命 

(с) 一 个 开发 软件 的 阶段 性 方法 
2. 瀑布 生存 周期 模型 是 什么 ? 
(а) 在 瀑布 下 开发 的 软件 


(b ) 一 个 开发 软件 的 可 循环 方法 
(4) 在 循环 中 所 开发 的 软件 的 生命 


(b) 一 个 过 程 模型 ， 在 这 个 模型 中 每 一 个 阶段 在 下 一 个 阶段 开始 之 前 完成 
(с) 一 个 过 程 模型 ， 在 这 个 模型 中 各 个 阶段 相互 重奏 
(4) 一 个 过 程 模 型 ， 在 这 个 模型 中 各 个 阶段 是 循环 的 

3. 下 面 哪 一 项 表示 了 瀑布 生存 周期 模型 的 局 限 性 ? 


Ca) 软件 是 按 阶段 被 开发 的 


(b) 每 一 个 阶段 在 下 一 个 阶段 开始 之 前 被 完成 


(с) 软件 开发 是 循环 进行 的 


(а) 除非 一 个 可 用 的 系统 被 开发 完成 ， 否 则 不 适合 测试 软件 需求 
4. 下 面 哪个 方法 能 克服 上 一 个 问题 中 所 指出 的 局 限 性 ? 


(а) 分 阶段 软件 开发 
(с) 演化 式 原型 
5. 什么 是 演化 式 原 型 ? 
(а) 分 阶段 软件 开发 
(с) 风险 驱动 的 开发 
6. 螺旋 模型 强调 的 方法 是 什么 ? 
(а) 分 阶段 软件 开发 
(c ) 风险 驱动 的 开发 
7. 软件 确认 的 目标 是 什么 ? 
(a) 构造 系统 
(с) 正确 地 构造 系统 
8. 软件 验证 的 目标 是 什么 ? 
(a) 构造 系统 
(с) 正确 地 构造 系统 
9. 什么 是 “ 白 盒 ”测试 ? 
(a) 单元 测试 
(c ) 使 用 系统 内 部 知识 的 测试 
10. FLE “RA” WR? 
(а) 系统 测试 
(с) 使 用 系统 内 部 知识 的 测试 


(Ь) 抛弃 型 原型 
(4) 增 量 开发 


(b) 抛弃 型 原型 
(а) 增 量 开发 


(b) 抛弃 型 原型 
(4) 增 量 开发 


(b) 构造 正确 的 系统 
(d) 测试 系统 


(b) 构造 正确 的 系统 
(а) 测试 系统 


(b) 集成 测试 
(4) 不 使 用 系统 内 部 知识 的 测试 


(b) 集成 测试 
(4) 不 使 用 系统 内 部 知识 的 测试 
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软件 设计 和 体系 结构 概念 





本 章 描 述 软件 设计 的 关键 概念 ， 这 些 概念 在 很 长 一 段 时 间 内 体现 了 对 软件 体系 结构 设计 
的 价值 。 首 先 ， 介绍 面 向 对 象 的 概念 ， 主 要 描述 其 中 所 包含 的 对 象 和 类 的 概念 。 随 后 ， 本 章 
讨论 在 面向 对 象 设 计 中 信息 隐藏 的 角色 ， 同 时 对 继承 的 概念 也 进行 了 介绍 。 本 章 接 着 介绍 了 
并 发 处 理 以 及 并 发 应 用 中 并 发 对 象 的 概念 。 在 这 之 后 ， 对 软件 设计 模式 、 软 件 体系 结构 以 及 
基于 构件 系统 的 主要 特征 进行 了 概述 。 最 后 ， 讨 论 软件 质量 属性 的 概念 。 本 章 中 的 示例 均 使 
用 UML 进行 描述 ，UML 表示 法 的 概述 可 参见 本 书 第 2 章 。 

本 章 的 内 容 结构 如 下 : 4.1 节 对 面向 对 象 概念 进行 概述 。4.2 节 描 述 信 息 隐 藏 。4.3 节 描 述 
继承 和 泛 化 / 特 化 关系 。4.4 节 概 述 了 并 发 处 理 。4.5 节 对 软件 设计 模式 进行 概述 ， 具 体 的 模 
式 则 将 在 随后 的 章节 中 描述 。4.6 节 概 述 软件 体系 结构 和 基于 构件 系统 的 主要 特征 。 最 后 ，4.7 
节 介 绍 软件 质量 属性 。 


4.1 面向 对 象 概念 


面向 对 象 程 编 程 和 Smalltalk 中 首次 引入 了 面向 对 象 ( object-oriented ) 这 个 术语 ， 尽 管 
言 息 隐藏 和 继承 中 的 面向 对 象 的 概念 可 能 出 现 得 更 早 。 信 息 隐 藏 及 其 在 软件 设计 中 的 使 用 可 
追溯 至 Parnas ( 1972 )， 他 倡导 使 用 信息 隐藏 作为 设计 模块 的 一 种 方式 ， 通 过 这 种 方式 设计 
出 的 模块 更 为 自 包含 (独立 )， 因 此 当 其 发 生变 化 时 对 其 他 模块 仅 会 产生 少量 的 影响 ， 甚 至 
没有 影响 。Simula 67 ( Dahl and Hoare 1972) 首次 使 用 了 类 和 继承 的 概念 ， 但 这 些 概念 仅 在 
Smalltalk 被 提出 之 后 才 开始 获得 广泛 接受 。 

在 软件 开发 中 ， 面 向 对 象 的 概念 非常 重要 ， 因 为 它们 解决 了 基本 的 适应 与 演化 问题 。 由 
于 软件 开发 中 面向 对 象 模 型 尤其 有 利于 演化 和 变更 ， 因 此 软件 建 模 方法 从 面向 对 象 的 视角 进 
行 开展 。 本 节 描 述 了 问题 ( 分 析 ) 层 和 解决 方案 ( 设计 ) 层 的 面向 对 象 概念 。 


对 象 和 类 





一 个 对 象 是 现实 世界 中 物理 的 或 概念 的 实体 ， 它 提供 了 对 现实 世界 的 理解 ， 并 因此 形成 
了 软件 解决 方案 的 基础 。 一 个 现实 世界 的 对 象 可 具有 物理 属性 〈 它 们 能 被 看 到 或 被 触摸 到 ), 
例如 一 扇 门 、 一 辆 汽车 或 一 慢 灯 。 一 个 概念 对 象 是 更 抽象 的 概念 ， 例 如 一 个 账户 或 一 次 交易 。 

面向 对 象 的 应 用 由 对 象 组 成 。 从 设计 的 视角 来 说 ， 一 个 对 象 涵盖 了 数据 (ааа) 以 
及 作用 于 数据 之 上 的 过 程 (procedure )， 这 些 过 程 通常 被 称 为 操作 (operation ) 或 者 方法 
(method )。 一 些 建 模 方法 (包括 UML 表示 法 ) 将 操作 定义 为 一 个 对 象 所 执行 功能 的 规约 ， 
同时 将 方法 定义 为 该 功能 的 实现 (Rumbaugh et al. 2005 )。 在 本 书 中 ， 术 语 操 作 既 代表 规格 说 
明 ， 也 代表 实现 ， 这 与 Gamma (2005), Meyer (2000) 以 及 其 他 学 者 所 指 的 一 致 。 

一 个 操作 的 签名 (signature) 代表 该 操作 的 名 字 、 参 数 以 及 返回 值 。 一 个 对 象 的 接口 
(interface) 是 它 提 供 的 操作 的 集合 ， 这 些 操 作 通 过 签名 定义 。 一 个 对 象 的 类 型 通过 它 的 接 
口 来 定义 ， 对 象 的 实现 则 由 它 的 类 来 定义 。 因 此 ，Meyer 将 一 个 类 定义 为 一 种 抽象 数据 类 型 
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( abstract data type ) 的 实现 ( Meyer 2000 ). 

对 象 (也 被 叫做 一 个 对 象 实例 ) 是 一 个 简单 的 “事物 ”， 例 如 John 的 汽车 或 者 Магу 的 账 
号 。 一 个 类 (也 被 叫做 一 个 对 象 类 ) 是 具有 相同 特征 的 对 象 的 集合 ， 例 如 “账户 ”( Account )、 
“E” (Employee) “RE” (Саг) 或 者 “客户 ”( Customer )。 图 4-1 描述 了 一 个 Customer 类 
和 两 个 对 象 ， 分 别 是 aCustomer 和 anotherCustomer。 这 两 个 对 象 是 Customer 类 的 实例 。 另 外 ， 
对 象 anAccount 和 anotherAccount Œ Account 类 的 实例 。 

属性 (attribute) 是 由 类 中 的 对 象 所 持 有 的 一 个 数据 值 ， 每 一 个 对 象 的 属性 都 有 一 个 
特定 的 取 值 。 图 4-2 展示 了 一 个 带 有 属性 的 类 。Account 类 有 两 个 属性 : accountNumber 
和 balance。anAccount 和 anotherAccount 是 Account 类 的 两 个 对 象 。 每 一 个 account 对象 
的 属性 都 有 特定 的 取 值 。 例 如 对 象 anAccount 中 属性 accountNumber 的 取 值 是 1234， 对 象 
anotherAccount 中 属性 accountNumber 的 取 值 则 是 5678。 前 一 个 对 象 中 属性 balance 的 取 值 
是 $525.36， 后 一 个 对 象 中 属性 balance 的 取 值 则 是 $1897.44。 在 一 个 类 中 ， 属 性 名 是 唯一 的 ， 
尽管 不 同 的 类 可 能 拥有 相同 的 属性 名 ， 例 如 在 Customer 类 和 Employee 类 中 都 存在 名 为 name 
和 address 的 属性 。 


ан, 
accountNumber : Integer 
balance : Real 
anotherCustomer : 
Customer 
anotherAccount : 
Account 


具有 取 值 的 对 象 


accountNumber = 1234 accountNumber = 5678 
balance = 525.36 balance = 1,897.44 


图 4-1 类 和 对 象 示例 图 4-2 具有 属性 的 类 示例 


操作 是 由 一 个 对 象 所 执行 的 一 项 功能 的 规约 。 一 个 对 象 可 拥有 一 个 或 多 个 操作 。 操 作对 
对 象 所 包含 的 属性 值 进行 操控 。 操 作 可 具有 输入 和 输出 参 
数 。 在 同一 个 类 中 的 所 有 对 象 拥有 相同 的 操作 。 例 如 ， ыен 
Account 类 有 readBalance, credit, debit, open 和 close 操 palanca.: Red 
YE. FA 4-3 展示 了 带 有 操作 的 Account 2. 

一 个 对 象 是 一 个 类 的 实例 。 在 执行 阶段 ， 单 个 对 象 按 
照 需 求 被 实例 化 。 每 一 个 对 象 都 有 一 个 独一无二 的 标识 ， 5 
该 标识 是 将 该 对 象 与 其 他 对 象 进行 区 分 的 特征 。 在 某 些 情 “图 4-3 具有 属性 和 操作 的 类 示例 
况 下 ,该 标识 可 能 是 一 个 属性 ( 例如 ， 一 个 账户 号 码 或 者 
一 个 客户 名 称 )， 但 它 不 一 定 必须 是 一 个 属性 。 设 想 有 两 个 蓝 色 的 球 ， 从 各 个 方面 来 看 它们 都 | 


р 


是 一 样 的 ， 然 而 它们 却 具 有 不 同 的 标识 。 47 


42 信息 隐藏 
信息 隐藏 是 与 所 有 软件 系统 设计 相关 的 一 个 基本 的 软件 设计 概念 。 由 于 早期 系统 普遍 使 














readBalance () ; Real 
credit (amount : Real) 
debit (amount : Real) 
open (accountNumber ; Integer) 
close () 
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用 全 局 数据 ， 因 此 这 些 系统 经 常 容易 出 错 并 且 难 以 修改 。Parnas (1972, 1979) 指出 通过 使 
用 信息 隐藏 ， 开 发 者 能 够 通过 大 量 减 少 或 者 在 理想 情况 下 完全 消除 全 局 数据 的 方式 将 软件 系 
统 设计 得 更 易 修 改 。Parnas 主张 将 信息 隐藏 作为 软件 系统 分 解 成 模块 的 一 种 标准 。 每 一 个 信 
息 隐 藏 模块 应 当 隐 藏 一 个 可 能 会 发 生变 化 的 设计 决策 。 每 一 个 可 变 的 决策 被 称 为 模块 的 秘密 
(secret )。 使 用 这 种 方法 后 ， 就 可 实现 为 变化 而 设计 (design for change ) 的 目标 。 


4.2.1 面向 对 象 设计 中 的 信息 隐藏 


信息 隐藏 是 面向 对 象 设 计 中 的 基本 概念 。 在 设计 对 象 的 时 候 ， 特 别 是 当 要 确定 什么 信息 
应 是 可 见 的 ， 什 么 信息 应 被 隐藏 时 ， 就 要 使 用 信息 隐藏 。 一 个 对 象 中 不 需要 被 其 他 对 象 看 到 
的 那些 部 分 应 当 被 隐藏 起 来 。 因 此 ， 如 果 对 象 的 内 部 发 生变 化 ， 仅 仅 会 影响 这 个 对 象 。 另 外 ， 
术语 封装 (encapsulation ) 也 被 用 来 描述 由 对 象 带 来 的 信息 隐藏 。 

使 用 了 信息 隐藏 ， 那 些 很 有 可 能 发 生变 化 的 信息 被 封装 ( 即 隐藏 ) 在 一 个 对 象 中 。 这 
个 信息 仅 能 通过 对 操作 进行 调用 而 被 外 界 间 接地 访问 (访问 过 程 或 函数 )， 这 些 操作 同时 
也 是 对 象 的 组 成 部 分 。 只 有 这 些 操作 能 够 直接 地 访问 信息 ; 因此 被 隐藏 的 信息 以 及 能 够 访 
问 它 的 操作 就 被 绑 定 在 一 起 ， 形 成 了 一 个 信息 隐藏 对 象 (information hiding object )。 操 
作 的 规约 ( 即 操作 的 名 字 和 参数 ) 被 称 为 对 象 接口 。 对 象 接口 也 被 称 为 抽象 接口 (abstract 
interface )、 虚 拟 接 口 (virtual interface ) 或 外 部 接口 (external interface )。 接 口 表 示 了 对 
象 的 可 见 部 分 ， 即 对 象 中 与 用 户 相 关 的 部 分 。 其 他 对 象 则 通过 接口 调用 这 个 对 象 所 提供 的 
操作 。 

在 应 用 软件 开发 中 ， 一 个 潜在 的 问题 是 可 能 需要 改变 那些 被 几 个 对 象 访问 的 重要 的 数据 
结构 。 在 没有 信息 隐藏 的 情况 下 ， 对 数据 结构 的 任何 改变 都 可 能 需要 修改 访问 该 数据 结构 的 
所 有 对 象 。 使 用 信息 隐藏 就 能 将 与 该 数据 结构 相关 的 设计 决策 、 其 内 部 连接 以 及 操纵 该 数据 
结构 的 操作 细节 隐藏 起 来 。 信 息 隐藏 所 带 来 的 解决 方案 将 数据 结构 封装 在 一 个 对 象 之 中 ， 仅 
能 通过 对 象 的 操作 才能 直接 地 访问 该 数据 对 象 。 

其 他 对 象 仅 能 通过 调用 对 象 的 操作 来 间接 地 访问 被 封装 起 来 的 数据 结构 。 因 此 ， 如 果 数 
据 结构 发 生变 化 ， 仅 会 对 包含 该 数据 结构 的 对 象 产 生 影 响 。 由 这 个 对 象 支持 的 外 部 接口 不 会 
发 生 改 变 ， 因 此 间接 访问 这 个 数据 结构 的 对 象 不 会 受到 这 个 变化 的 影响 。 这 种 信息 隐藏 的 形 
式 被 称 为 数据 抽象 ( data abstraction )。 


4.22 ”信息 隐藏 示例 


接 下 来 将 给 出 一 个 软件 设计 中 信息 隐藏 的 示例 ， 该 示例 会 和 不 使 用 信息 隐藏 的 功能 式 方 
法 进行 比较 。 为 了 解释 信息 隐藏 的 好 处 ， 考 虑 功能 式 方 法 和 信息 隐藏 对 下 列 问 题 的 解决 方案 。 
几 个 模块 访问 一 个 栈 ; 在 功能 式 解 决 方案 中 模块 是 过 程 或 郴 数 ， 而 在 信息 隐藏 解决 方案 中 则 
是 对 象 。 在 功能 式 解决 方案 中 ， 栈 是 一 个 全 局 的 数据 结构 。 使 用 这 种 方法 ， 每 一 个 模块 都 直 
接 访问 这 个 栈 ， 因 此 为 了 能 够 对 栈 进 行 操 纵 ， 每 一 个 模块 都 需要 知道 这 个 栈 的 表示 形式 (Ж 
组 或 链表 ) ( 图 4-4 )。 

信息 隐藏 解决 方案 是 将 栈 的 表示 形式 ( 例如 ， 数 组 ) 在 需要 访问 该 栈 的 对 象 的 视角 上 隐 
藏 起 来 。 一 个 信息 隐藏 对 象 ( 栈 对 象 ) 的 设计 如 下 (图 4-5 ): 
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Module B 


个 Max Size = № 








Module A 








Al 4-4 全 局 访问 栈 数组 示例 


Ж: 该 图 不 符合 ОМІ 表示 法 。 


栈 的 信息 
隐藏 对 象 








图 4-5 由 数组 实现 的 栈 信息 隐藏 对 象 示例 
注 : 该 图 不 符合 UML 表示 法 。 


© 定义 一 组 操作 来 操纵 数据 结构 。 在 栈 的 示例 中 ， 典 型 的 操作 是 push, рор. full 以 及 
empty。 

e 定义 数据 结构 。 例 如 ， 在 栈 的 示例 中 ， 定 义 了 一 个 一 维 数组 。 另 外 ， 定 义 了 一 个 指示 
栈 顶 端的 变量 ， 以 及 一 个 表示 队列 长 度 的 变量 。 

© 不 允许 其 他 对 象 访问 这 个 数据 结构 。 它 们 能 够 调用 对 象 的 操作 来 向 栈 顶 推 人 一 个 元 
素 ， 或 者 从 栈 中 取出 一 个 元 素 。 

现在 假设 对 栈 的 设计 从 一 个 数组 改变 为 一 个 链表 ， 考 虑 这 个 变化 对 功能 式 解决 方案 和 信 


息 隐 藏 解决 方案 带 来 的 影响 。 在 两 个 解 пива нове 






决 方案 中 ， 栈 的 数据 结构 都 得 改变 。 然 
而 ， 在 功能 式 的 解决 方案 中 ， 栈 由 一 个 
全 局 的 数据 结构 实现 ， 由 于 每 一 个 访问 
这 个 栈 的 模块 都 直接 操作 了 这 个 数据 结 
构 ， 因 此 这 些 模块 都 必须 改变 。 改 变 后 ， 
模块 必须 操纵 链表 的 指针 ， 而 不 再 操纵 
数组 的 索引 (图 4-6 )。 

在 信息 隐藏 解决 方案 中 ， 除 了 内 部 图 4-6 全 局 访问 栈 链表 示例 
的 栈 数 据 结构 发 生 巨 大 变化 之 外 ， 信 息 2: 该 图 不 符合 UML 表示 法 。 
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隐藏 对 象 的 操作 细节 也 必须 改变 ， 因 为 它们 现在 要 访问 一 个 链表 而 不 是 一 个 数组 ( 图 4-7 )。 
然而 ， 对 其 他 对 象 可 见 的 外 部 接口 却 不 需要 修改 。 因 此 ， 使 用 这 个 栈 的 对 象 不 会 受到 这 种 变 
化 的 影响 ， 它 们 可 以 继续 调用 对 象 的 操作 ， 甚 至 不 需要 知道 已 经 发 生 的 变化 。 





图 4.7 “由 链表 实现 的 栈 信息 隐藏 对 象 示例 

Ж: 该 图 不 符合 UML 表示 法 。 

同样 的 概念 可 以 适用 于 设计 一 个 栈 类 ， 这 个 类 作为 创建 栈 对 象 的 模板 。 如 图 4-8 所 示 定 
义 了 一 个 栈 类 ， 这 个 类 隐藏 了 栈 所 需要 使 用 的 数据 结构 ， 并 
指定 了 操纵 数据 结构 的 操作 。 根 据 需 要 ， 应 用 可 以 实例 化 单 | 
独 的 栈 对 象 。 每 一 个 栈 对 象 都 有 它 自 己 的 标识 。 同时 ， 每 一 push (in item) 
个 栈 对 象 都 拥有 它 自己 的 栈 数据 结构 的 本 地 拷贝 ， 以 及 栈 操 [омлет en 
作 需 要 的 其 他 实例 变量 的 本 地 拷贝 。 he rl 


4.23 设计 信息 隐藏 对 象 图 4-8 ”一 个 栈 信息 隐藏 类 示例 





前 一 小 节 列 举 的 两 个 示例 主要 是 为 了 解释 信息 隐藏 的 好 处 。 通 过 抽取 对 象 的 内 部 复杂 性 ， 
封装 提升 了 抽象 的 层次 ， 认 识 到 这 一 点 是 十 分 重要 的 。 这 种 方式 提升 了 粒度 的 尺寸 。 开 发 者 
只 需要 考虑 接口 ， 而 不 是 内 部 的 复杂 性 。 因 此 ， 在 栈 示例 中 ， 我们 不 需要 从 最 初 就 考虑 栈 的 
内 部 实现 细节 。 实 际 上 ， 我 们 应 当 通 过 考虑 一 个 对 象 应 提供 怎样 的 接口 来 开始 设计 一 个 信息 
隐 茂 对象。 例如， 在 设计 栈 的 时 候 ， 接 口 需要 提供 push, рор, empty 和 full 操作。 对 于 一 个 
消息 队列 来 说 ， 应 当 有 将 一 个 消息 入 队 和 出 队 的 操作 ， 而 队列 的 实际 数据 结构 可 以 稍 后 才 被 
确定 。 当 将 信息 隐藏 应 用 于 IO 设备 接口 的 设计 时 ， 其 中 的 关键 问题 是 构成 虚拟 设备 接口 的 
操作 的 规约 ， 而 不 是 如 何 与 现实 设备 连接 的 细节 。 

因此 ， 一 个 对 象 〈 或 类 ) 的 设计 分 为 两 步 : 首先 设计 作为 外 部 视图 的 接口 ， 随 后 设计 内 
部 细节 。 第 一 步 是 高 层 设计 的 一 部 分 ， 而 第 二 步 则 是 详细 设计 的 一 部 分 。 由 于 经 常 需 要 对 哪 
些 是 外 部 可 见 的 而 哪些 是 外 部 不 可 见 的 进行 权衡 ， 因 此 设计 很 可 能 是 一 个 迭代 的 过 程 。 通 常 ， 
暴露 出 封装 在 对 象 中 的 所 有 变量 也 不 是 一 个 很 好 的 主意 ， 例 如 通过 get 和 set 操作 ， 这 意味 着 
被 隐藏 的 信息 很 少 。 


43 ”继承 和 泛 化 / 特 化 
继承 是 分 析 和 设计 中 的 一 个 有 用 的 抽象 机 制 。 继 承 很 自然 地 为 那些 在 某 些 方面 相似 但 也 
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不 是 完全 相似 的 对 象 进行 建 模 ; 因此 ， 这 些 对 象 具有 一 些 共同 的 特性 ， 也 包含 一 些 唯 一 的 特 
性 用 来 区 分 它们 。 继 承 是 一 种 已 被 广泛 使 用 于 其 他 领域 的 分 类 机 制 。 例 如 ， 动 物 世界 的 分 类 
法 将 动物 划分 成 哺乳 类 ， 鱼 类 、 扑 行 类 ， 等 等 。 猎 和 狗 具有 共同 的 特性 ， 这 些 特 性 能 够 被 泛 
化 为 哺乳 动物 的 特性 。 然 而 ， 它 们 也 具有 唯一 的 特性 (例如 ， 狗 能 呐 叫 而 猫 只 能 鄙 晓 叫 )。 

继承 是 在 不 同类 中 分 享 和 复 用 代码 的 机 制 。 一 个 子 类 (child class ) 继承 其 父 类 (parent 
class) 的 特性 (被 封装 的 数据 和 操作 )。 随 后 它 能 够 修改 其 父 类 的 结构 ( 被 封装 的 数据 ) 
和 行为 (操作 )。 父 类 被 称 为 超 类 (superclass ) 或 者 基 类 (base class )。 子 类 被 称 为 子 类 
(subclass) 或 者 是 派生 类 (derived class )。 将 父 类 进行 修改 从 而 形成 子 类 的 过 程 被 称 为 特 化 。 
子 类 可 以 被 进一步 特 化 ， 这 样 就 创建 出 了 类 的 层次 结构 ， 这 也 叫做 泛 化 / 特 化 层次 结构 。 

类 继承 是 一 种 通过 复 用 父 类 的 功能 而 扩展 应 用 系统 功能 的 机 制 。 因 此 ， 使 用 已 存在 的 类 
能 够 增 量 地 定义 一 个 新 的 类 。 一 个 子 类 能 够 更 改 其 父 类 所 封装 的 数据 (被 称 为 实例 变量 ) 和 
操作 。 通 过 增加 新 的 实例 变量 ， 子 类 就 能 够 更 改 这 些 封装 的 数据 。 通 过 增加 新 的 操作 或 者 重 
新 定义 现 有 的 操作 ， 子 类 就 能 够 更 改 父 类 中 的 操作 。 一 个 子 类 也 有 可 能 废弃 父 类 的 操作 ; Ж 
而 ， 不 推荐 这 种 做 法 ， 因 为 在 这 种 情况 下 ， 子 类 不 再 共享 父 类 的 接口 。 

在 如 图 4-9 所 示 的 银行 账户 示例 中 ，CheckingAccount 和 SavingsAccount 拥有 一 些 共同 的 
属性 ， 其 他 的 则 是 不 同 的 属性 。 在 所 有 账户 中 都 相同 的 属性 〈 即 accountNumber 和 balance ) 
被 作为 了 父 类 Account 的 属性 。 特 定 于 一 个 SavingsAccount 的 属性 ， 例 如 cumulativelnterest 
(在 这 个 银行 中 ，CheckingAccount 不 累计 利息 ) 则 被 作为 子 类 SavingsAccount 的 属性 。 
类 似 地 ， 特 定 于 一 个 CheckingAccount 的 属性 ， 例 如 lastDepositAmount， 被 作为 了 子 类 
CheckingAccount 的 属性 。 












# accountNumber : Integer 
# balance : Real = 0 


+ readBalance () : Real 
+ credit (amount : Real) 
+ debit (amount : Real) 
+ open (accountNumber : Integer) 
+ close () 











CheckingAccount 


SavingsAccount 


- cumulativelnterest : Real = 0 


+ addInterest (interestRate : Real) 
+ readCumulativelnterest () : Real 


图 4-9 泛 化 / 特 化 层次 结构 示例 
每 一 个 子 类 都 增加 了 新 的 操作 。 在 子 类 SavingsAccount 中， 增加 的 新 操作 是 read 
CumulativeInterest， 它 用 来 读 取 “ 累 计 的 利息 ”(cumulativeInterest )， 男 外 ， 新 增 addInterest 
操作 来 增加 每 日 的 利息 (interest )。， 对 于 子 类 CheckingAccount 来 说 ， 新 增加 的 操作 是 
readLastDepositAmount。 第 14 章 将 更 加 详细 地 描述 这 个 示例 。 


44 并 发 处 理 
一 个 对 象 可 能 是 主动 的 ， 也 可 能 是 被 动 的 。 对 象 经 常 是 被 动 的 ， 也 就 是 说 ， 它 们 等 待 另 





- lastDepositAmount : Real = 0 










+ credit (amount : Real 
+ readLastDepositAmount() : Real 
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一 个 对 象 来 调用 它们 的 操作 ， 并 且 从 不 启动 任何 行动 。 而 一 些 面向 对 象 的 方法 和 语言 (例如 
Ada 和 Java) 支持 主动 的 对 象 。 主 动 对 象 也 被 称 为 并 发 对 象 ， 独 立 于 其 他 的 主动 对 象 而 执行 。 


4.4.1 ”顺序 应 用 与 并 发 应 用 


顺序 应 用 是 一 个 顺序 的 程序 ， 它 由 一 组 被 动 对 象 组 成 并 且 仅 有 一 个 控制 线程 。 当 一 个 对 
象 调用 另 一 个 对 象 的 操作 时 ， 控 制 就 会 从 调用 操作 传递 到 被 调用 的 操作 。 当 被 调用 的 操作 执 
行 完毕 时 ， 控 制 就 会 返回 到 调用 的 操作 。 在 一 个 顺序 应 用 中 ， 仅 支持 同步 的 消息 通信 ( 过 程 
调用 或 方法 调用 )。 

在 一 个 并 发 应 用 中 ,通常 有 几 个 并 发 对 象 ， 每 一 个 对 象 都 拥有 属于 它 自 己 的 控制 线程 。 
并 发 应 用 支持 异步 的 消息 通信 ， 因 此 一 个 并 发 的 源 对 象 能 够 向 一 个 并 发 的 目标 对 象 发 送 一 条 
异步 的 消息 ， 源 对 象 随后 继续 执行 ， 而 不 用 考虑 目标 对 象 何 时 接收 到 这 条 信息 。 如 果 消 息 到 
达 时 目标 对 象 很 繁忙 ， 那 么 消息 就 会 被 缓存 。 


442 并 发 对 象 


并 发 对 象 也 叫做 主动 对 象 、 并 发 过 程 、 并 发 任务 或 者 线程 (Gomma 2000 )。 一 个 并 发 对 
& ( 主动 对 象 ) 拥有 自己 的 控制 线程 并 能 独立 于 其 他 的 对 象 而 执行 。 被 动 对 象 拥有 被 并 发 对 
象 所 调用 的 操作 。 被 动 对 象 也 能 调用 其 他 被 动 对 象 中 的 操作 。 被 动 对 象 没 有 控制 线程 ， 因 此 
它们 是 被 动 类 的 实例 。 被 动 对 象 中 的 一 个 操作 一 旦 被 并 发 对 象 调用 ， 就 会 在 并 发 对 象 的 控制 
线程 中 执行 。 

一 个 并 发 对 象 表示 一 个 顺序 程序 的 执行 ， 或 者 是 并 发 程序 中 一 个 顺序 构件 的 执行 。 每 一 
个 并 发 对 象 处 理 一 个 顺序 执行 的 线程 ， 因 此 在 一 个 并 发 对 象 中 不 允许 存在 并 发 的 操作 。 然 而 ， 
整个 系统 的 并 发 是 通过 多 个 并 发 对 象 的 并 行 执行 来 实现 的 。 并 行 对 象 经 常 异 步 地 执行 ( 即 ， 
以 不 同 的 速度 )， 并 且 在 一 段 很 长 的 时 间 内 彼此 相互 独立 。 有 时 ， 并 发 对 象 需要 和 其 他 对 象 进 
行 通 信 并 同步 它们 之 间 的 行动 。 
443 并 发 对 象 间 的 协作 


在 并 发 系统 的 设计 中 ， 需 要 考虑 几 个 不 会 在 顺序 系统 设计 过 程 中 出 现 的 问题 。 在 大 多 数 
的 并 发 应 用 中 ， 并 发 对 象 必须 相互 协作 来 完成 应 用 所 需 的 服务 。 当 并 发 对 象 相互 协作 时 ， 通 
常会 出 现下 面 三 个 问题 : 

1) 当 并 发 对 象 需要 互 斥 地 访问 资源 (例如 共享 的 数据 或 物理 设备 ) 时 ， 会 出 现 互 斥 问题 
( mutual exclusion problem )。 这 个 问题 的 另外 一 种 形式 是 多 读者 - 写 者 (mnultiple readers and 
writers ) 问题 ， 其 中 互 斥 的 约束 有 时 会 被 放宽 。 

2) 当 两 个 并 发 对 象 需要 互相 同步 它们 的 操作 时 ， 就 会 发 生 同 步 问 题 (synchronization 
problem )。 

3 ) 当 并 发 对 象 需要 相互 通信 从 而 将 数据 从 一 个 并 发 对 象 传 向 另 一 个 并 发 对 象 时 ， 就 会 发 
生生 产 者 / 消费 者 问题 (producer/consumer problem )。 并 发 对 象 之 间 的 通信 经 常 被 称 为 进程 间 
通信 (IPC )。 


4.4.4 同步 问题 
当 两 个 任务 需要 在 没有 进行 数据 通信 的 情况 下 同步 它们 的 操作 时 ， 就 会 使 用 事件 同步 。 
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源 任务 执行 一 个 信号 〈 事 件 ) 操作 ， 这 表示 一 个 事件 已 经 发 生 。 事 件 同步 是 异步 的 。 在 UML 
中 ， 这 两 个 任务 被 描绘 为 主动 对 象 ， 同 时 存在 从 发 送 任务 发 送 到 接收 任务 的 异步 事件 信和 号 。 
目标 任务 执行 一 个 等 待 (事件 ) 操作 ， 这 个 操作 将 任务 挂 起 直至 源 任 务 已 经 发 出 了 事件 。 如 
果 事 件 已 被 发 出 ， 那 么 目标 任务 就 不 会 被 挂 起 。 下 面 给 出 一 个 示例 。 

并 发 对 象 间 同 步 的 示例 

考虑 一 个 来 源 于 并 发 机 器 人 系统 的 事件 同步 的 例子 。 每 一 个 机 器 人 系统 被 设计 为 一 个 
并 发 的 对 象 并 且 控制 一 个 移动 的 机 器 人 手臂 。 一 个 执行 拾取 和 放置 动作 的 机 器 人 【pick-and- 
place robot ) 将 物件 带 到 工作 场地 ， 另 一 个 钻 孔 机 器 人 【〈 drilling robot) 就 能 在 物件 上 钻 四 个 
孔 。 当 钻 孔 操作 完成 后 ， 拾 取 和 放置 机 器 人 将 物件 移 走 。 

这 里 需要 解决 多 个 同步 问题 。 第 一 ， 存 在 一 个 碰撞 区 域 ， 在 这 个 区 域 中 拾取 - 放置 机 器 
人 和 钻 孔 机 器 人 的 手臂 可 能 发 生 碰 撞 。 第 二 ， 拾 取 - 放置 机 器 人 必须 在 钻 孔 机 器 人 开始 钻 孔 
之 前 放置 物件 。 第 三 ， 钻 孔 机 器 人 必须 在 拾取 - 放置 机 器 人 移 走 物件 之 前 完成 钻 孔 。 对 于 这 
些 问 题 的 解决 方案 采用 事件 同步 ， 如 下 文 所 述 。 

拾取 - 放置 机 器 人 将 物件 移动 到 工作 场地 ， 从 碰撞 区 域 离 开 ， 然 后 发 出 partReady 的 事 
件 。 这 个 信号 将 钻 孔 机 器 人 唤醒 ， 使 其 移动 至 工作 场地 并 且 进 行 钻 孔 。 在 完成 钻 孔 操作 之 后 ， 


钻 孔 机 器 人 离开 碰撞 区 域 ， 随 后 发 出 第 二 个 信号 
pore | 


partCompleted， 这 个 信号 是 拾取 - 放置 机 器 人 
一 直 在 等 待 接收 的 信号 。 

在 被 信号 唤醒 之 后 ， 拾 取 - 放置 机 器 人 移 图 4-10 并 发 对 象 间 同 步 示 例 
走 物件 。 每 一 个 机 器 人 执行 一 次 循环 ， 因 为 机 器 
人 重复 地 执行 着 它们 的 操作 。 以 上 所 述 的 解决 方案 如 下 (也 可 参见 图 4-10): 

拾取 - 放置 机 器 人 


while workAvailable do 
Pick up part 
Move part to work location 
Release part 
Move robot arm to safe position 
signal (partReady) 
wait (partCompleted) 
Pick up part 
Remove part from work location 
Place part 

end while; 


钻 孔 机 器 人 


while workAvailable do 
wait (partReady) 
Move robot arm to work location 
Drill four holes 
Move robot arm to safe position 
signal (partCompleted) 

end while; 


1: partReady 
-一 > 










=— 
2: partCompleted 
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445 生产 者 / 消费 者 问题 


并 发 系统 中 的 一 个 共同 问题 是 生存 者 并 发 对 象 和 消费 者 并 行 对 象 之 间 存 在 的 问题 。 生 产 
者 并 发 对 象 生产 信息 ， 然 后 消费 者 并 发 对 象 消费 这 个 信息 。 在 一 个 并 发 系统 中 ， 每 一 个 并 发 
对 象 拥有 它 自 己 的 控制 线程 ， 同 时 这 些 并 发 对 象 异步 地 执行 。 因 此 当 并 发 对 象 间 希 望 交换 数 
据 时 ， 同 步 并 发 对 象 间 的 操作 是 有 必要 的 。 由 此 生产 者 必须 在 消费 者 消费 数据 之 前 就 生产 出 
数据 。 如 果 消 费 者 已 准备 接收 数据 但 生产 者 还 未 生产 出 数据 ， 那 么 消费 者 必须 等 待 生产 者 。 
如 果 生 产 者 在 消费 者 准备 接收 数据 之 前 就 已 经 生产 了 数据 ， 那 么 要 么 阻止 生产 者 继续 生产 ， 
要 么 将 这 些 数据 为 消费 者 缓存 起 来 从 而 允许 生产 者 继续 生产 。 

对 这 个 问题 的 一 个 通用 的 解决 方案 是 在 生产 者 和 消费 者 并 发 对 象 之 间 使 用 消息 通信 。 两 
个 并 发 对 象 之 间 的 消息 通信 含有 两 个 目的 : 

1) 将 数据 从 一 个 生产 者 〈 源 ) 并 发 对 象 转移 到 一 个 消费 者 〈 目标 ) 并 发 对 象 。 

2) 在 生产 者 和 消费 者 之 间 进 行 同步 。 如 果 没 有 消息 ， 消 费 者 必须 等 待 来 自生 产 者 的 消 
息 。 在 某 些 情况 下 ,生产 者 等 待 来 自 消费 者 的 回复 。 

并 发 对 象 间 的 消息 通信 可 能 是 同步 的 ， 也 可 能 是 异步 的 。 在 一 个 分 布 式 应 用 中 ， 同 步 对 
象 可 能 位 于 相同 的 结 点 ， 也 可 能 散布 在 多 个 不 同 结 点 上 。 如 果 使 用 异步 消息 通信 ， 生 产 者 向 
消费 者 发 送 消息 后 能 够 继续 执行 而 不 等 竺 回复。 如 果 使 用 同步 消息 通信 ， 生 产 者 向 消费 者 发 
送 消 息 后 立即 等 待 回 复 。 


446 异步 消息 通信 


异步 消息 通信 也 叫做 松 耦 合 的 消息 通信 ， 使 用 这 种 通信 方式 ， 生 产 者 向 消费 者 发 送 消息 
后 要 么 不 需要 得 到 回复 ， 要 么 在 收 到 回复 之 前 执行 其 他 的 功能 。 因 此 ， 生 存 者 发 出 消息 后 继 
续 执 行 而 不 需要 等 待 回复 。 消 费 者 接收 消息 。 由 于 生产 者 和 消费 者 并 发 对 象 以 不 同 的 速度 执 
行 其 功能 ， 因 此 能 够 在 生产 者 和 消费 者 之 间 建 立 一 个 先 人 先 出 ( FIFO ) 消息 队列 。 当 消费 者 
请 求 一 个 消息 而 队列 中 没有 消息 时 ， 消 费 者 就 会 被 挂 起 。 

图 4-11 给 出 了 一 个 异步 消息 通信 的 示例 。 在 这 个 示例 中 ， 生 产 者 并 发 对 象 向 消费 者 并 发 


对 象 发 送 消息 。 一 个 FIFO 消息 队列 存在 于 生产 者 和 消费 者 之 间 。 
Ба 


Е 
4.4.7” 带 回复 的 同步 消息 通信 

带 回复 的 同步 消息 通信 也 叫做 带 回复 的 紧 耦 合 的 消息 通信 ， 使 用 这 种 通信 方式 ， 生 产 者 
发 送 一 条 消息 给 消费 者 后 就 等 待 回复 。 当 消息 到 达 时 ， 消 费 者 接收 消息 ， 处 理 它 ， 生 成 一 个 
回复 ， 然 后 发 送 该 回复 。 随 后 生产 者 和 消费 者 均 继续 执行 。 如 果 没 有 消息 时 ， 消 费 者 就 会 被 
挂 起 。 在 一 对 给 定 的 生产 者 和 消费 者 之 间 不 存在 消息 队列 。 同 时 ， 正 如 第 12 章 将 要 描述 的 那 
样 ， 也 存在 不 带 回复 的 同步 消息 通信 设计 模式 。 

带 回复 的 同步 消息 通信 的 示例 如 图 4-12 所 示 ， 其 中 生产 者 向 消费 者 发 送 一 条 消息 ， 在 接 
收 到 信息 之 后 ， 消 费 者 就 向 生产 者 发 送 一 个 回复 。 


1: sendAsynchronousMessage (in message) 
—> 














[ 4-11 Я (PABA ) 消息 通信 
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aProducer aConsumer 


Р 4-12 带 回复 的 同步 ( 紧 耦 合 ) 消息 通信 


1: sendSynchronousMessageWithReply 
(in message, out response) 
一 一 














45 设计 模式 


在 软件 设计 中 ， 开 发 者 时 常会 遇 到 一 个 在 以 往 的 不 同 项 目 中 已 经 得 到 解决 的 问题 。 问 题 
的 上 下 文 经 常 是 不 同 的 ， 它 可 能 是 不 同 的 应 用 、 不 同 的 平台 或 者 不 同 的 编程 语言 。 这 种 不 同 
的 上 下 文 常常 会 导致 开发 者 重新 设计 并 且 重 新 实现 这 个 解决 方案 ， 因 此 就 掉 人 了 “重新 发 明 
齿轮 ”的 陷阱 中 。 软 件 模式 这 个 领域 (包括 体系 结构 和 设计 模式 ) 正在 帮助 开发 者 避免 那些 
不 必要 的 重新 设计 和 重新 实现 。 

Christopher Alexander 在 建筑 物 的 体系 结构 中 首次 提出 了 模式 的 概念 ， 并 且 他 的 书 «The 
Timeless Way of Building» ( Alexander 1970) 对 这 个 概念 进行 了 描述 。Gamma、Helms、 
Johnson 和 Vlissides 的 书 «Design Patterns» ( 1995 ) 将 设计 模式 在 软件 行业 中 加 以 推广 ， 这 本 
书 描述 了 23 种 设计 模式 。 之 后 ，Buschmamm et al. ( 1996 ) 描述 了 跨越 不 同 抽象 层次 的 模式 ， 
从 高 层 的 体系 结构 模式 到 设计 模式 ， 再 到 低层 的 习惯 用 法 。 

设计 模式 描述 了 竺 解决 的 重复 出 现 的 设计 问题 、 对 问题 的 解决 方案 以 及 解决 方案 工作 的 
EFX (Buschmann et al. 1996 ; Gamma et al. 1995 )。 这 个 描述 指明 了 在 一 个 特殊 的 上 下 文中 
为 了 解决 一 个 普遍 存在 的 设计 问题 而 定制 的 对 象 和 类 。 由 于 涉及 多 个 类 并 且 涉 及 不 同 的 类 对 
象 之 间 的 交互 ， 因 此 设计 模式 是 一 个 比 类 的 粒度 更 大 的 复 用 方式 。 设 计 模式 有 时 被 称 作 为 微 
体系 结构 (microarchitecture ) 

在 设计 模式 的 概念 最 初 获得 成 功 之 后 ， 其 他 类 型 的 模式 也 被 不 断 开发 出 来 。 可 复 用 的 模 
式 主要 包括 以 下 几 种 类 型 : 

ө 设计 模式 。 在 这 本 被 大 量 引用 的 书 (Gamma et al. 1995) 中 ， 四 位 软件 设计 师 Erich 
Gamma, Richard Helm, Ralph Johnson 和 John Vlissides 描述 了 设计 模式 。 这 四 位 设计 
师 在 某 些 方面 被 称 为 “四 人 帮 ”。 一 个 设计 模式 是 一 小 组 协作 的 对 象 。 
体系 结构 模式 。Buschmann et al. (1996) 在 西门 子 描述 了 这 项 工作 。 体 系 结构 模式 比 
设计 模式 的 粒度 更 大 ， 它 用 于 定义 一 个 系统 中 主要 子 系统 的 结构 。 

分 析 模 式 。Fowler (2002) 描述 了 这 个 模式 ， 他 在 分 析 不 同 应 用 领域 的 过 程 中 找到 了 
相似 性 。 他 描述 了 在 面向 对 象 分 析 中 发 现 的 重复 出 现 的 模式 ， 并 且 用 静态 模型 ( 类 
图 ) 对 其 进行 描述 。 

特定 产品 线 的 模式 。 这 些 模 式 在 特定 的 领域 中 被 使 用 ， 例 如 工厂 自动 化 领域 (Gomma 
2005) 或 者 电子 商业 领域 。 通 过 关注 特定 的 应 用 领域 ,设计 模式 能 够 提供 更 适合 于 特 
定 领域 的 解决 方案 。 

习惯 用 法 。 习 惯用 法 是 低层 的 特定 于 给 定 的 编程 语言 的 设计 模式 ,它们 描述 了 使 用 语 
言 特 性 ( 例如 Java 或 C++ 的 特性 ) 而 对 一 个 问题 产生 的 实现 方案 。 这 些 模式 最 接近 
代码 ， 但 是 它们 仅 能 被 用 同样 的 编程 语言 编写 的 应 用 所 使 用 。 


4.6 软件 体系 结构 和 构件 
软件 体系 结构 (Bass et al. 2003 ; Shaw and Garlan 1996) 使 用 构件 及 其 连接 的 方式 ， 将 
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系统 的 整体 结构 与 单个 构件 的 内 部 实现 细节 进行 分 离 。 本 节 描 述 构件 接口 的 设计 ， 这 在 软件 
体系 结构 中 是 一 个 重要 的 问题 。 在 描述 供给 接口 、 请 求 接口 以 及 连接 构件 的 连接 器 之 前 ， 本 
节 描 述 接口 是 如 何 被 定义 的 。 


4.6.1 构件 和 构件 接口 


可 以 以 不 同 的 方式 使 用 构件 这 个 术语 。 一 般 意义 上 ， 构 件 经 常用 于 表示 模块 化 系统 ， 系 
统 中 的 模块 依赖 于 特定 的 平台 或 软件 体系 结构 以 不 同 的 方式 被 开发 出 来 。 

构件 是 自 包含 的 (通常 是 并 发 的 ) 且 具 有 良好 定义 接口 的 对 象 ， 它 能 够 在 与 最 初 设计 不 
同 的 应 用 中 被 使 用 。 为 了 完全 指定 一 个 构件 ， 使 用 它 所 提供 的 操作 以 及 它 所 需要 的 操作 来 进 
行 定义 是 非常 必要 的 ( Magee et al. 1994 ; Shaw and Garlan 1996 )。 这 样 的 定义 与 传统 的 面向 
对 象 方法 形成 对 照 ， 传 统 的 面向 对 象 方法 仅仅 使 用 它 提 供 的 操作 来 定义 一 个 对 象 。 然 而 ， 如 
果 将 一 个 已 有 的 构件 集成 到 一 个 基于 构件 的 系统 中 时 ， 理 解构 件 需 要 的 操作 以 及 它 提 供 的 操 
作 是 非常 重要 的 ， 因 此 要 将 这 些 接 口 显 式 地 描述 出 来 。 


4.6.2 ”连接 器 


除了 定义 构件 之 外 ,一 个 软件 体系 结构 必须 定义 将 构件 结合 起 来 的 连接 器 。 一 个 连接 器 
封装 了 两 个 或 多 个 构件 之 间 的 互 连 协 议 。 构 件 间 不 同 种 类 的 消息 通信 和 包括 异步 通信 ARA ) 
和 同步 通信 ( 紧 耦 合 )。 每 一 种 通信 类 型 的 互 连 协议 都 能 被 封装 在 一 个 连接 器 中 。 例 如 ， 尽 管 
在 同一 结 点 上 的 构件 间 异 步 消息 通信 在 逻辑 上 与 那些 在 不 同 结 点 上 的 构件 之 间 的 通信 和 是 相同 
的 ,在 这 两 种 情况 中 仍 会 使 用 不 同 的 连接 器 。 在 前 一 种 情况 中 ， 连 接 器 使 用 共享 的 内 存 缓冲 ; 
后 一 种 情况 则 使 用 在 网 络 上 发 送 消息 的 连接 器 。 


47 软件 质量 属性 


软件 质量 属性 (Bass, Clements, and Катап 2003 ) 指 软件 的 质量 需求 ， 通 常 也 被 称 为 
非 功能 性 需求 。 在 软件 体系 结构 设计 中 要 明确 考虑 每 一 个 非 功能 性 需求 。 在 开发 软件 体系 结 
构 时 处 理 并 评估 质量 属性 能 够 对 软件 产品 的 质量 产生 深远 的 影响 。 质 量 属性 包括 : 
o 可 维护 性 (maintainability )。 在 软件 部 署 之 后 它 能 够 被 更 改 的 程度 。 
可 修改 性 (modifiability )。 在 最 初 开 发 期 间 和 最 初 开发 之 后 软件 能 够 被 修改 的 程度 。 
可 测试 性 (testability )。 软 件 能 够 被 测试 的 程度 。 
可 追踪 性 (traceability )。 每 一 个 阶段 的 产品 能 够 被 追踪 到 上 一 个 阶段 产品 的 程度 。 
可 伸缩 性 〈scalability )。 在 最 初 部 署 之 后 系统 能 够 成 长 的 程度 。 
可 复 用 性 (reusability )。 软 件 能 够 被 复 用 的 程度 。 
性 能 (performance )。 系 统 满足 其 性 能 目标 的 程度 ， 例 如 吞吐 量 和 响应 时 间 。 
安全 性 (security )。 系 统 抵御 安全 威胁 的 程度 。 
可 用 性 (availability )。 系 统 能 够 解决 系统 失效 问题 的 程度 。 


48 总 结 


本 章 描述 了 软件 设计 的 主要 概念 以 及 基于 构件 的 软件 体系 结构 的 重要 概念 。 本 章 介绍 的 
面向 对 象 的 概念 形成 了 接 下 来 几 章 的 基础 。 第 7 章 描述 了 静态 建 模 如 何 应 用 于 软件 系统 的 建 
模 。 第 9 章 、 第 10 章 和 第 11 章 描述 了 动态 建 模 如 何 用 于 软件 系统 的 建 模 。 其 中 ,第 9 章 和 





第 11 章 介绍 了 使 用 对 象 交互 建 模 的 对 象 间 动 态 建 模 技 术 。 第 10 章 介 绍 了 使 用 有 限 状态 机 对 


一 个 对 象 的 内 部 行为 进行 动态 建 模 。 


本 章 使 用 软件 质量 属性 这 一 术语 介绍 了 非 功能 性 需求 。 在 第 6 章 中 详 述 了 非 功 能 性 需求 ， 
而 第 20 章 描述 了 在 软件 体系 结构 中 怎样 处 理 软件 质量 属性 。 第 12 章 更 加 详细 地 对 设计 模式 


进行 了 描述 。 


另外 ， 本 章 也 描述 了 基于 构件 的 软件 体系 结构 的 概念 ， 强 调 了 构件 的 基础 而 非 技 术 ， 构 
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件 的 技术 通常 是 频繁 变化 的 。 第 17 章 将 进一步 描述 基于 构件 的 软件 体系 结构 的 开发 。 


练习 


选择 题 ( 每 道 题 选择 一 个 答案 ) 
1. 下 列 哪 一 项 是 面向 对 象 的 概念 ? 
(а) 模块 和 接口 

(с) 类 、 信 息 隐 藏 和 继承 

2. 下 列 哪 一 项 是 对 象 的 特性 ? 
(а) 一 个 函数 或 子 过 程 


(с) 一 组 数据 和 对 数据 进行 操作 的 过 程 


3. 什么 是 类 ? 

(а) 一 个 对 象 实例 

(с) 具有 相同 特征 的 对 象 的 集合 
4. 什么 是 类 的 操作 (或 方法 7 


(а) 被 一 个 类 执行 的 函数 的 规约 和 实现 

(b) 被 一 个 类 提供 的 子 例 程 的 规约 和 实现 
(с) 被 一 个 类 提供 的 函数 或 过 程 的 规约 和 实现 
(4) 被 一 个 类 提供 的 接口 的 规约 和 实现 


5. 什么 是 操作 的 签名 ? 

(a) 操作 的 名 字 

(с) 操作 的 名 字 、 人 参数 和 返回 值 
6. 什么 是 类 的 接口 ? 

(a) 类 的 签名 

(с) 类 的 内 部 细节 
7. 什么 是 属性 ? 

(а) 类 的 描述 

(c) 类 具有 的 数据 项 
8. 什么 是 软件 设计 的 信息 隐藏 ? 
(а) 隐藏 信息 从 而 使 得 它 不 被 发 现 
(c ) 隐藏 信息 让 信息 安全 
9. 什么 是 数据 抽象 ? 

(а) 信息 隐藏 的 另 一 个 名 字 
(с) 在 数据 库 中 存储 数据 
10. 什么 是 继承 ? 

(а) 从 父 类 中 继承 特性 的 机 制 
(с) 在 类 间 共 享 数 据 的 机 制 


(b) 模块 和 信息 隐藏 
(4) 并 发 和 信息 隐藏 


(b) 一 个 模块 
(4) 一 组 函数 和 算法 


(b) 对 象 的 实现 
(а) 具有 不 同 特征 的 对 象 的 集合 


(b ) 操作 的 函数 或 子 例 程 
(d) 对 象 的 接口 


(b ) 类 提供 的 操作 的 规约 
(d) 类 的 实现 


(b) 类 的 内 部 性 质 
(d) 类 的 参数 


(b) 隐藏 很 可 能 发 生变 化 的 设计 决策 
Cd) 将 数据 封装 在 一 个 类 中 


СЬ) 封装 数据 从 而 隐藏 其 结构 
(4) 在 数据 结构 中 存储 数据 


(b) 在 类 间 共 享 和 复 用 代码 的 机 制 
(4) 在 类 间 隐 藏 信息 的 机 制 
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软件 建 模 和 设计 方法 概览 





本 书 描述 的 软件 建 模 和 设计 方法 称 为 COMET (Collaborative Object Modeling and Arch- 
itectural Design Method， 协 作 的 对 象 建 模 和 体系 结构 设计 方法 )。 该 方法 使 用 UML 表示 法 。 
COMET 是 一 个 迭代 的 用 例 驱 动 和 面向 对 象 的 方法 ， 它 特别 强调 了 软件 开发 生存 周期 的 需求 、 
分 析 和 设计 建 模 阶 段 。 本 章 从 软件 生存 周期 的 角度 考虑 COMET 方法 。COMET 方法 的 开发 过 
程 是 一 个 基于 用 例 的 软件 过 程 ， 与 统一 软件 开发 过 程 (Unified Software Development Process, 
USDP ) (Jacobson, Booch, and Rumbaugh 1999) 和 螺旋 模型 (Boehm 1988) 兼容 。 本 章 展示 
了 COMET 的 基于 用 例 的 软件 生存 周期 ， 并 描述 了 COMET 方法 如 何 与 USDP 或 者 螺旋 模型 一 
起 使 用 。 接 着 ， 概 述 了 对 COMET 方法 的 主要 活动 ， 并 总 结 了 在 使 用 COMET 时 的 步骤 。 

5.1 节 描 述 COMET 基于 用 例 的 软件 生存 周期 5.2 节 把 COMET 方法 与 其 他 软件 过 程 进 
行 比 较 5.3 节 给 出 COMET 方法 中 需求 、 分 析 和 设计 建 模 活动 的 概述 ; 5.4 节 给 出 本 书 中 不 
同 种 类 的 软件 体系 结构 设计 的 概述 。 


5.1 COMET 基于 用 例 的 软件 生存 周期 


COMET 基于 用 例 的 软件 生存 周期 模型 是 一 种 围绕 用 例 概 念 的 高 度 迭 代 的 软件 开发 过 
程 。 在 需求 模型 中 ， 用 参与 者 和 用 例 来 描述 系统 的 功能 性 需求 。 每 个 用 例 定义 了 一 个 或 多 
个 参与 者 与 系统 之 间 的 交互 序列 。 在 分 析 模 型 中 ， 实 现 用 例 以 描述 参与 用 例 的 对 象 以 及 它们 
之 间 的 交互 。 在 设计 模型 中 ， 开 发 软件 体系 结构 ， 以 描述 构件 以 及 它们 之 间 的 接口 。 完 整 
的 COMET 基于 用 例 的 软件 生存 周期 模型 如 图 5-1 所 示 。COMET 生存 周期 是 高 度 迭 代 的 。 
COMET 方法 通过 基于 用 例 的 方法 将 需求 、 分 析 和 设计 建 模 三 个 阶段 结合 在 一 起 。 


5.1.1 需求 建 模 


在 需求 建 模 阶 段 ， 所 开发 的 需求 模型 使 用 参与 者 和 用 例 描述 了 系统 的 功能 性 需求 。 每 个 
用 例 要 开发 一 个 叙述 性 描述 。 在 此 过 程 中 ， 用 户 的 输入 和 主动 的 参与 是 必 不 可 少 的 。 如 果 需 
求 没 有 被 很 好 地 理解 ,那么 可 以 开发 一 个 抛弃 型 原型 来 帮助 河清 需求 (参见 第 2 章 )。 


5.1.2 分 析 建 模 


在 分 析 建 模 阶 段 ， 要 开发 系统 的 静态 和 动态 模型 。 静 态 模型 定义 了 问题 域 类 之 间 的 结构 
关系 。 这 些 类 及 其 关系 描绘 在 类 图 中 。 对 象 的 组 织 准则 用 来 决定 在 分 析 模 型 中 要 考虑 哪些 对 
象 。 然 后 ， 开 发 动态 模型 来 实现 来 自 需求 模型 的 用 例 ， 以 显示 每 个 用 例 中 参与 的 对 象 以 及 对 
象 间 是 如 何 交 互 的。 对 象 和 它们 之 间 的 交互 描绘 在 通信 图 或 者 顺序 图 中 。 在 动态 模型 中 ,使 
用 状态 图 来 定义 状态 相关 的 对 象 。 


513 设计 建 模 
在 设计 建 模 阶 段 ， 要 设计 系统 的 软件 体系 结构 。 在 此 阶段 中 ， 分析 模型 被 映射 到 一 个 运 
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行 环境 。 分 析 模 型 ( 强调 的 是 问题 域 ) 被 映射 到 设计 模型 ( 强调 的 是 解 域 ) 中 。 此 阶段 提供 
子 系统 的 组 织 准则 来 将 系统 组 织 为 子 系统 。 子 系统 被 视 为 聚合 或 者 复合 对 象 。 将 分 布 式 的 子 
系统 设计 为 使 用 消息 相互 通信 的 可 配置 构件 时 ， 要 给 予 特别 的 考虑 。 接 着 设计 每 个 子 系统 。 
对 于 顺序 系统 ， 重 点 放 在 信息 隐藏 、 类 和 继承 的 面向 对 象 的 概念 。 对 于 并 发 系统 的 设计 ， 例 
如 实时 的 、 客 户 端 / 服 务 器 〈《C/S ) 和 分 布 式 应 用 ， 除 了 考虑 面向 对 象 的 概念 外 ， 还 需要 考虑 
并 发 任务 的 概念 。 


5.1.4 增 量 软件 构建 


在 软件 体系 结构 设计 完成 之 后 ， 就 要 采用 增 量 软件 构建 方法 。 该 方法 是 基于 为 每 次 增 量 
55 选择 系统 的 一 个 子 集 进行 构建 。 子 集 的 确定 是 通过 选择 要 包含 在 该 增 量 中 的 用 例 和 参与 这 些 
‚| 用 例 的 对 象 。 增 量 软件 构建 包含 了 该 子 集中 类 的 详细 设计 、 编 码 和 单元 测试 。 这 是 一 个 分 阶 
63) 段 的 方法 ,通过 该 方法 ， 软 件 被 逐渐 地 构建 和 集成 ， 直 到 整个 系统 构造 完成 。 


5.1.5” 增 量 软 件 集成 


在 增 量 软件 集成 期 间 ， 要 执行 每 个 软件 增 量 的 集成 测试 。 增 量 的 集成 测试 是 基于 为 该 增 
量 选择 的 用 例 。 为 每 个 用 例 都 要 开发 集成 测试 用 例 。 集 成 测试 是 白 盒 测试 的 一 种 形式 ， 对 参 
与 每 个 用 例 的 对 象 之 间 的 接口 都 进行 了 测试 。 

每 个 软件 增 量 形成 一 个 增 量 原型 。 在 软件 增 量 被 判定 为 符合 要 求 后 ， 就 通过 增 量 软件 构 
建 和 增 量 软 件 集成 这 两 个 阶段 进行 迭代 ， 构 建 和 集成 下 一 个 增 量 。 然 而 ， 如 果 在 软件 增 量 中 
检测 出 重要 的 问题 ， 那 么 可 能 就 需要 在 需求 建 模 、 分 析 建 模 和 设计 建 模 阶段 中 进行 迭代 。 


5.1.6 ”系统 测试 


系统 测试 包括 系统 的 功能 测试 ， 即 针对 系统 的 功能 性 需求 测试 系统 。 这 种 测试 是 黑 盒 测 
试 ， 基 于 黑 合用 例 。 因 此 ， 要 为 每 一 个 黑 盒 用 例 构 建功 能 测试 用 例 。 发 布 给 客户 的 任何 软件 


5.2 COMET 生存 周期 与 其 他 软件 过 程 的 比较 


本 节 将 COMET 生存 周期 与 统一 软件 开发 过 程 (USDP ) 和 螺旋 模型 进行 简要 的 比较 。 
COMET 方法 可 以 和 USDP 或 螺旋 模型 联合 使 用 。 


5.2.1 COMET 生存 周期 与 统一 软件 开发 过 程 对 比 


USDP (Jacobson, Booch, and Rumbaugh (1999), 第 3 章 作 了 简要 介绍 ) 强调 了 过 程 和 
方法 (方法 相对 于 过 程 其 外 延 更 小 一 些 )。USDP 方法 提供 了 关于 生存 周期 方面 的 相当 多 的 细 
节 以 及 关于 使 用 方法 的 一 些 细节 。COMET 方法 与 USDP 兼容 。USDP 的 工作 流 就 是 需求 、 分 
析 、 设 计 、 实 现 和 测试 的 工作 流 。 
COMET 生存 周期 的 每 个 阶段 都 对 应 USDP 中 的 一 个 工作 流 。COMET 的 前 三 个 阶段 
与 USDP 的 前 三 个 工作 流程 有 着 相同 的 名 字 。 这 一 点 并 不 意外 ， 因 为 COMET 生存 周期 受到 
Jacobson 早期 工作 (Jacobson 1992 ) 的 强烈 影响 。COMET 增 量 软件 构建 活动 对 应 于 USDP 的 
实现 工作 流 。COMET 的 增 量 软 件 集成 和 系统 测试 阶段 映射 到 USDP 的 测试 工作 流 。COMET 
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之 所 以 将 这 些 活 动 分 开 是 因为 集成 测试 被 看 作 开发 团队 的 活动 ， 而 系统 测试 应 该 由 分 离 的 测 
试 团 队 来 承担 。 


5.2.2 COMET 生存 周期 与 螺旋 模型 对 比 


COMET 方法 也 能 够 与 螺旋 模型 (Boehm 1998 ) 同时 使 用 。 在 为 螺旋 模型 的 一 个 给 定 周 
期 进行 项 目 计划 期 间 ， 项 目 经 理 要 决定 在 项 目 开 发 象限 (第 三 象限 ) 中 执行 哪些 特定 的 技术 
活动 。 被 选中 的 技术 活动 ( 例如 需求 建 模 、 分 析 建 模 或 者 设计 建 模 ) 都 将 会 在 第 三 象限 中 执 
行 。 在 第 二 象限 中 执行 的 风险 分 析 活 动 和 在 第 四 象限 中 执行 的 周期 计划 决定 了 在 每 个 技术 活 
动 中 需要 多 少 次 迭代 。 


5.3 需求、 分 析 和 设计 建 模 


UML 表示 法 支持 需求 、 分 析 和 设计 概念 。 本 书 描述 的 COMET 方法 将 需求 活动 、 分 析 活 
动 和 设计 活动 分 开 。 需 要 强调 的 是 ，UML 模型 需要 补充 附加 的 信息 才能 完全 地 描述 软件 体系 
结构 。 

需求 建 模 解决 开发 系统 的 功能 性 和 非 功能 性 需求 。COMET 区 分 分 析 和 设计 如 下 : 分 析 
是 拆 解 或 分 解 问题 ， 以 便 问 题 能 够 被 更 好 地 理解 ; 设计 是 综合 解决 方案 或 组 合 解决 方案 (把 
解决 方案 放 在 一 起 )。 这 些 活 动 将 在 后 续 小 节 中 详细 描述 。 


5.3.1 需求 建 模 中 的 活动 


在 需求 模型 中 ， 系 统 被 认为 是 一 个 黑 盒 。 要 开发 用 例 模 型 。 

e 用 例 建 模 。 定 义 参 与 者 和 黑 盒 用 例 。 系 统 的 功能 性 需求 采用 用 例 和 参与 者 来 描述 。 用 
例 描述 是 一 个 行为 视图 ; 用 例 之 间 的 关系 给 出 了 一 个 结构 视图 。 用 例 建 模 详 见 第 6 章 。 

о 陈述 非 功能 性 需求 。 这 在 需求 阶段 也 很 重要 。UML 表示 法 没有 陈述 这 个 问题 。 然 而 ， 
可 以 对 用 例 建 模 方法 进行 补充 来 陈述 非 功能 性 需求 ， 如 第 6 章 所 述 。 


5.3.2 ”分 析 建 模 中 的 活动 


在 分 析 模 型 中 ， 重 点 是 理解 问题 ; 因此 ， 重 点 在 标识 问题 域 中 的 对 象 以 及 对 象 之 间 传 递 
的 信息 。 有 些 问题 要 推迟 到 设计 阶段 ,例如 对 象 是 主动 的 还 是 被 动 的 ， 消 息 发 送 是 异步 的 还 
是 同步 的 ， 以 及 接收 对 象 调用 哪些 操作 等 。 
在 分 析 模 型 中 ， 考 虑 的 是 对 问题 域 的 分 析 。 其 活动 如 下 : 
о 静态 建 模 。 定 义 特定 问题 的 静态 模型 。 这 是 系统 中 提供 信息 的 结构 视图 。 类 是 由 它们 
的 属性 及 其 和 其 他 类 之 间 的 关系 定义 的 。 操 作 在 设计 模型 中 定义 。 对 于 信息 密集 系 
统 ， 该 视图 是 非常 重要 的 。 重 点 是 在 问题 域 中 对 现实 世界 的 类 进行 信息 建 模 。 静 态 建 
模 将 在 第 7 章 中 详细 介绍 。 
ө 对 象 的 组 织 。 决 定 参 加 每 个 用 例 的 对 象 。 给 出 对 象 的 组 织 准则 ， 以 帮助 确定 系统 中 的 
软件 对 象 : 哪些 是 实体 对 象 、 边 界 对 象 、 控 制 对 象 以 及 应 用 逻辑 对 象 。 对 象 组 织 将 在 
第 8 章 中 介绍 。 在 对 象 确定 之 后 ， 对 象 之 间 的 动态 交互 将 在 动态 模型 中 描述 。 
• 动态 交互 建 模 。 实 现 用 例 来 显示 参与 每 个 用 例 的 对 象 之 间 的 交互 。 开 发 通信 图 或 顺序 
图 来 显示 对 象 如 何 相互 通信 来 执行 用 例 。 第 9 章 描述 了 无 状态 的 动态 建 模 ， 包 括 动态 
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交互 建 模 方法 ， 它 是 用 来 帮助 确定 对 象 之 间 如 何 交互 来 支持 用 例 的 。 第 11 章 描述 了 状 
态 相 关 的 动态 交互 建 模 ， 其 中 对 状态 相关 的 控制 对 象 间 的 交互 和 它们 执行 的 状态 图 进 
行 了 显 式 地 建 模 。 

© 动态 状态 机 建 模 。 系 统 的 状态 相关 的 视图 使 用 层次 状态 图 来 定义 。 每 个 状态 相关 的 对 
象 由 其 状态 图 来 定义 。 设 计 有 限 状 态 机 和 状态 图 详 见 第 10 章 。 


5.3.3 设计 建 模 中 的 活动 


在 设计 模型 中 ， 考 虑 的 是 解 域 。 在 这 个 阶段 中 ， 分 析 模 型 被 映射 到 一 个 并 发 设计 模型 。 
为 了 设计 软件 体系 结构 ， 将 执行 以 下 活动 : 
ө 集成 对 象 通 信 模 型 。 开 发 集成 的 对 象 通信 图 。 详 见 第 13 章 。 
© 做 关于 子 系统 结构 和 接口 的 决策 。 开 发 总 体 的 软件 体系 结构 。 将 应 用 组 织 为 子 系统 。 
详 见 第 13 章 。 
© 做 关于 在 软件 体系 结构 中 使 用 什么 软件 体系 结构 模式 和 设计 模式 的 决策 。 软 件 体 系 结 
构 模 式 详 见 第 12、15、16、17 和 18 章 。 
© 做 关于 类 接口 的 决策 ， 特 别 是 对 于 顺序 软件 体系 结构 。 对 每 个 子 系统 ， 设 计 信息 隐藏 
类 (被 动 类 )。 设 计 每 个 类 的 操作 和 每 个 操作 的 参数 。 详 见 第 14 章 。 
© 做 关于 如 何 将 分 布 式 应 用 组 织 为 分 布 式 子 系统 的 决策 ， 其 中 子 系统 被 设计 成 为 可 配置 
的 构件 ， 并 且 定 义 构 件 之 间 的 消息 通信 接口 。 详 见 第 13、15、16 和 17 章 。 
ө 做 关于 对 象 特性 的 决策 ， 特 别 是 它们 是 主动 的 还 是 被 动 的 。 对 于 每 个 子 系统 ， 将 系统 
组 织 为 并 发 的 任务 ( 主动 对 象 )。 在 任务 的 组 织 过 程 中 ， 使 用 任务 组 织 准 则 来 组 织 任 
务 ， 并 定义 任务 的 接口 。 详 见 第 18 章 。 
ө 做 关于 消息 特性 的 决策 ， 特 别 是 它们 是 同步 的 还 是 异步 的 (要 回复 还 是 不 要 回复 )。 
体系 结构 通信 模式 详 见 第 12、13、15、16、17 #118 章 。 
COMET 强调 在 分 析 和 设计 过 程 中 的 特定 阶段 使 用 组 织 准 则 。 对 象 组 织 准则 用 来 帮助 确 
定 系 统 中 的 对 象 ; 子 系统 组 织 准 则 用 来 帮助 确定 子 系统 ; 并 发 对 象 组 织 准 则 用 来 确定 系统 中 
并 发 (主动 ) 对象。 贯穿 始终 地 使 用 UML 构造 型 来 清晰 地 显示 组 织 准 则 的 使 用 。 


54 设计 软件 体系 结构 


在 软件 设计 建 模 期 间 ， 根 据 软 件 体系 结构 的 特性 来 做 出 设计 决策 。 本 书 中 设计 建 模 部 分 
的 章节 描述 了 不 同 种 类 的 软件 体系 结构 的 设计 : 
© 面向 对 象 的 软件 体系 结构 。 第 14 章 使 用 信息 隐藏 、 类 和 继承 的 概念 来 描述 面向 对 象 
设计 。 
客户 端 /服务 器 软件 体系 结构 。 第 15 章 描述 了 客户 端 / 服务器 软件 体系 结构 设计 。 一 
个 典型 的 设计 包含 了 一 个 服务 器 和 多 个 客户 端 。 
e 面向 服务 的 体系 结构 。 第 16 章 描述 了 面向 服务 的 体系 结构 设计 ， 它 包含 了 多 个 分 布 
式 自治 服务 ， 这 些 服务 能 被 组 合成 分 布 式 软件 应 用 。 
. 基于 构件 的 分 布 式 软件 体系 结构 。 第 17 章 描 述 了 基于 构件 的 软件 体系 结构 设计 ， 可 
以 在 分 布 式 配置 的 分 布 式 平台 上 部 署 执行 。 
о 实时 软件 体系 结构 。 第 18 章 描述 了 实时 软件 体系 结构 设计 ， 这 通常 是 用 来 处 理 多 个 


BSF Жїнї} ЭМЕЙ 49 





输入 事件 流 的 并 发 体系 结构 。 它 们 典型 地 依赖 于 状态 ， 带 有 集中 的 或 分 散 的 控制 。 
© 软件 产品 线 体系 结构 。 第 19 章 描述 了 软件 产品 线 体 系 结构 设计 ， 这 种 体系 结构 是 为 


产品 族 的 ， 需 要 捕获 产品 族 中 的 共性 和 可 变性 。 [67 | 
5.5 BE 


本 章 描述 了 为 开发 基于 UML 面向 对 象 软件 应 用 的 COMET 基于 用 例 的 软件 生存 周期 。 
本 章 将 COMET 生存 周期 与 USDP 和 螺旋 模型 进行 了 对 比 ， 并 描述 了 COMET 如 何 与 USDP 
或 螺旋 模型 一 起 使 用 。 接 着 描述 了 COMET 方法 中 的 主要 活动 ， 并 总 结 了 使 用 COMET 的 步 
BR COMET 方法 中 的 每 个 步骤 将 在 本 书后 续 的 章节 中 加 以 更 详细 地 描述 。 

对 于 软件 密集 型 系统 ( 即 软件 是 一 个 更 大 的 硬件 /软件 系统 的 组 成 部 分 )， 系 统 建 模 可 以 
在 软件 建 模 之 前 实施 。UML 有 一 个 分 支 叫做 SysML， 它 是 一 个 面向 系统 工程 应 用 的 通用 目的 
的 建 模 语言 。 


练习 


以 下 间 题 与 本 书 中 描述 的 软件 建 模 和 设计 方法 (COMET ) 相关 。 

选择 题 ( 每 道 题 选择 一 个 答案 ) 

1. 需求 建 模 过 程 中 会 进行 以 下 哪 项 活动 ? 

(a) 系统 的 功能 性 需求 用 功能 、 输 入 和 输出 来 描述 

(b) 系统 的 功能 性 需求 用 参与 者 和 用 例 来 描述 

(с) 系统 的 功能 性 需求 用 文本 描述 

(4) 系统 的 功能 性 需求 通过 用 户 访谈 来 确定 
2. 分 析 建 模 过 程 中 会 进行 以 下 哪 项 活动 ? 


(a) 开发 用 例 模 型 (b) 开发 数据 流 图 和 实体 联系 图 
(c) 开发 静态 和 动态 模型 (4) 开发 软件 体系 结构 

з. 设计 建 模 过 程 中 会 进行 以 下 哪 项 活动 ? 

(a) 开发 用 例 模型 (b) 开发 数据 流 图 和 实体 联系 图 
(с) 开发 静态 和 动态 模型 (4) 开发 软件 体系 结构 


4. 增 量 软 件 构 建 中 会 实施 以 下 哪 项 活动 ? 
(а) 对 系统 的 一 个 子 集中 的 类 进行 详细 设计 和 编码 
(b) 对 系统 的 一 个 子 集中 的 类 进行 详细 设计 、 编 码 和 单元 测试 
(с) 对 系统 的 一 个 子 集 中 的 类 进行 编码 和 单元 测试 
(4) 对 系统 的 一 个 子 集中 的 类 进行 单元 测试 和 集成 测试 
5. 增 量 软件 集成 过 程 中 会 进行 以 下 哪 项 活动 ? 


(а) 实现 每 个 软件 增 量 中 的 类 (Cb) 单元 测试 每 个 软件 增 量 中 的 类 
(с) 集成 测试 每 个 软件 增 量 中 的 类 (4) 系统 测试 每 个 软件 增 量 中 的 类 
6. 在 系统 测试 期 间 会 进行 以 下 哪 种 测试 ? 

(а) 白 盒 测试 (b) 黑 盒 测试 


(с) 单元 测试 (а) 集成 测试 
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第 6 章 | 


Software Modeling & Design: UML, Use Cases, Patterns, & Software Architectures 


用 例 建 模 





系统 的 需求 描述 了 用 户 对 系统 的 期 望 ; 换言之 ， 即 系统 将 为 用 户 做 些 什 么 。 当 定 义 系统 
的 需求 时 ， 该 系统 应 该 被 看 作 一 个 黑 盒 ， 使 得 只 有 系统 的 外 部 特性 才 被 考虑 。 功 能 性 需求 和 
非 功能 性 需求 都 需要 被 考虑 。 需 求 建 模 包含 了 需求 分 析 和 需求 规约 。 

用 例 建 模 是 一 种 描述 系统 的 功能 性 需求 的 方法 〈 将 如 本 章 所 述 )。 系 统 的 数据 需求 ( 以 需 
要 被 系统 存储 的 信息 而 言 ) 是 使 用 静态 建 模 ( 见 第 7 童 ) 来 确定 的 。 系 统 的 输入 和 输出 首先 
在 用 例 模 型 中 描述 ， 然 后 在 静态 建 模 过 程 中 进行 细 化 。 

6.1 节 概 述 软 件 需求 分 析 和 规约 ， 接 着 描述 了 用 于 定义 功能 性 需求 的 用 例 方 法 ， 以 及 扩展 
用 例 来 描述 非 功 能 性 需求 。 本 章 还 描述 了 参与 者 ( actor ) 和 用 例 (Cuse case) 的 概念 ， 然 后 介 
绍 用 例 间 的 关系 ， 尤 其 是 包含 (include ) 和 扩展 (extend) 关系 。6.2 节 概 述 用 例 建 模 以 及 一 
个 简单 用 例 的 例子 。6.3 节 描 述 参 与 者 和 它们 在 用 例 建 模 中 的 角色 。6.4 节 涵 盖 如 何 标识 用 例 
这 一 重要 的 主题 。6.5 节 描 述 如 何 将 用 例文 档 化 。6.6 节 给 出 用 例 描述 的 一 些 例子 。6.7 节 描 述 
用 例 关 系 。 用 包括 关系 建 模 在 6.8 节 中 介绍 ; 用 扩展 关系 建 模 在 6.9 节 中 介绍 。6.10 节 描 述 用 
例 指 南 。6.11 节 描 述 规定 非 功 能 性 需求 。6.12 节 描 述 用 例 包 。6.13 节 描 述 如 何 使 用 活动 图 更 
精确 地 描述 用 例 。 


6.1 需求 建 模 


开发 一 个 新 的 软件 系统 有 两 个 主要 原因 : 替代 一 个 手工 系统 ， 或 者 替代 一 个 现存 的 软件 
系统 。 第 一 种 情况 中 ， 开 发 新 系统 来 替换 手工 系统 ， 而 手工 系统 的 记录 可 能 保存 在 纸 质 文档 
并 存放 在 档案 柜 中 。 另 一 种 情况 中 ， 开 发 新 系统 来 替换 严重 过 时 的 现存 软件 系统 ， 例 如 ， 因 
为 它 运 行 在 已 淘汰 的 硬件 上 《〈 例如 一 个 集中 式 的 主机 系统 ),， 或 者 因为 它 是 由 已 淘汰 的 语言 
《如 Cobol) 开发 的 并 且 (或 者 ) 该 系统 几乎 或 者 根本 没有 文档 。 是 开发 一 个 新 的 系统 还 是 蔡 
换 现存 的 系统 ， 精 确 和 明白 地 规定 新 系统 的 需求 是 非常 重要 的 。 在 系统 中 经 常 有 许多 用 户 ; 
在 一 个 大 公司 中 ， 可 能 有 工程 师 、 市 场 和 销售 人 员 、 经 理 、IT 人 员 、 行 政 人 员 等 。 每 个 用 户 
组 (常常 被 称 作 涉 众 ) 的 需求 必须 被 理解 和 规定 出 来 。 


611 需求 分 析 





软件 需求 描述 了 系统 必须 为 用 户 提 供 的 功能 。 需 求 分 析 包 含 了 分 析 需 求 ( 例如 ， 通 过 
用 户 访谈 ) 和 分 析 现 存 的 手工 或 自动 的 系统 。 询 问 用 户 的 问题 包括 下 面 这 些 : 你 在 当前 С 
工 的 或 自动 的 ) 系统 中 是 什么 角色 ? 你 是 如 何 使 用 当前 系统 的 ?当前 系统 的 优势 和 局 限 有 哪 
些 ? 新 系统 应 该 给 你 提供 哪些 特征 ? 分 析 一 个 现存 的 手工 系统 涉及 理解 当前 系统 和 对 当前 系 
统 进行 文档 记录 ,确定 当前 系统 的 哪些 特征 应 该 被 自动 化 、 哪 些 该 保持 手工 ， 以 及 和 用 户 讨 
论 在 系统 自动 化 时 哪些 功能 可 以 以 不 同 的 方式 完成 。 分 析 一 个 现存 软件 系统 需要 抽取 软件 需 
求 ， 将 功能 性 需求 从 产生 于 设计 或 实现 决策 的 功能 中 分 离 出 来 ， 标 识 非 功能 性 需求 ， 决 定 哪 
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些 功能 要 以 不 同 的 方式 完成 ， 以 及 要 增加 哪些 新 功能 。 
6.1.2 ”需求 规约 


在 分 析 之 后 ， 需 求 需 要 被 规约 化 。 需 求 规约 是 需要 需求 分 析 师 和 用 户 达成 共识 的 文档 。 
它 是 后 续 设 计 和 开发 的 起 点 ， 因 此 也 必须 被 开发 者 所 理解 。 功 能 性 需求 和 非 功能 性 需求 都 需 
要 被 规约 化 。 

功能 性 需求 描述 了 为 了 达到 系统 的 目的 系统 必须 能 够 提供 的 功能 。 在 定义 功能 性 需求 时 ， 
有 必要 描述 系统 需要 提供 什么 功能 ， 哪 些 信 息 需 要 从 外 部 环境 ( 例如 外 部 用 户 、 外 部 系统 或 
外 部 设备 ) 输入 给 系统 ， 哪 些 需要 由 该 系统 输出 给 外 部 环境 ， 以 及 哪些 存储 信息 该 系统 要 读 
取 或 更 新 。 例 如 ， 一 个 查看 银行 账户 余额 的 功能 性 需求 ， 用 户 需要 输入 账户 号 码 ， 系 统 需要 
从 客户 账户 读 取 余额 并 输出 该 余额 。 

非 功能 性 需求 有 时 也 被 称 作 质量 属性 ， 是 指 系 统 必须 满足 的 服务 质量 目标 。 非 功能 性 需 
求 的 例子 有 : 性 能 需求 ， 规 定 系统 响应 时 间 为 2 秒 ; 可 用 性 需求 ， 规 定 系统 必须 在 99% 的 时 
间 中 可 运行 ; 或 安全 性 需求 ， 如 防止 系统 被 人 侵 。 


6.1.3 ”软件 需求 规约 的 质量 属性 


以 下 属性 被 认为 有 利于 书写 好 的 软件 需求 规约 ( Software Requirements Specification, SRS ): 

о 正确 。 每 个 需求 都 是 对 用 户 需 要 的 精确 解释 。 

© 完整 。SRS 包含 了 每 个 有 意义 的 需求 。 另 外 ，SRS 需要 定义 系统 对 每 个 可 能 输入 的 响 
应 ,无 论 输 入 是 正确 的 或 错误 的 。 最 后 ， 不 应 有 任何 的 “待定 ”。 

• 无 二 义 。 这 意味 着 每 个 陈述 的 需求 只 有 一 个 解释 。 模 糊 的 陈述 都 必须 被 替换 。 

一 致 。 这 是 指 确保 单个 需求 之 间 不 冲突 。 可 能 会 有 冲突 的 术语 ， 例 如 两 个 术语 都 意 指 

同一 个 概念 ; 可 能 会 有 冲突 的 需求 ， 例 如 一 个 需求 做 出 了 一 个 关于 其 所 依赖 需求 的 错 

误 假 设 ; 还 可 能 在 后 续 的 阶段 添加 一 个 新 需求 时 ,会 和 已 有 的 需求 冲突 。 

可 验证 。 需 求 规约 实际 上 是 开发 者 和 客户 机 构 之 间 的 合同 。 软 件 验收 标准 是 开发 自 需 

求 规约 的 。 因 此 ， 每 个 需求 能 被 测试 以 确定 系统 满足 需求 是 必要 的 。 

非 计算 机 专家 能 够 理解 。 因 为 系统 的 用 户 很 可 能 是 非 计算 机 专家 ， 所 以 需求 规约 以 易 

理解 的 叙述 文字 书写 是 很 重要 的 。 

可 修改 。 因 为 需求 规约 很 可 能 经 过 多 次 迭代 ， 并 且 系 统 部 署 之 后 也 需要 演化 ， 所 以 需 

求 规约 可 修改 是 必要 的 。 为 了 辅助 该 目标 ,需求 规约 需要 有 目录 、 索 引 以 及 交叉 引 

用 。 每 个 需求 应 该 只 在 一 个 地 方 陈述 ， 否 则 ， 不 一 致 性 就 可 能 草 延 到 规约 中 。 

可 追踪 。 需 求 规约 需要 能 反 向 追踪 到 系统 级 需求 和 用 户 需要 ， 同 时 也 需要 能 向 前 追踪 

到 满足 需求 的 设计 部 件 和 实现 需求 的 代码 部 件 。 

在 开发 需求 规约 的 过 程 中 会 频繁 地 产生 困境 ， 因 为 上 述 这 些 目标 中 有 些 是 相互 冲突 的 。 
例如 ， 为 了 让 需求 规约 更 易 理解 可 能 会 和 让 其 一 致 和 无 二 义 的 目标 相 冲 突 。 在 需求 规约 过 程 的 
所 有 阶段 ， 用 户 参 与 是 必需 的 ， 以 确保 用 户 的 需要 包含 在 需求 规约 中 。 理 想 情况 下 ， 用 户 也 应 
当 在 需求 规约 的 团队 中 。 需 要 和 用 户 一 起 举行 多 次 评审 。 开 发 抛弃 型 原型 对 澄清 用 户 需求 是 有 
帮助 的 ( 详 见 第 3 章 )。 对 自动 化 一 个 手工 系统 而 言 ， 当 用 户 可 能 不 清楚 自动 化 系统 会 是 什么 
样子 时 ， 原 型 设计 会 非常 有 用 。 质 量 属性 的 概述 在 第 4 章 给 出 ， 更 详细 的 描述 见 第 20 章 。 
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6.2 用例 


在 用 例 建 模 方法 中 ， 功 能 性 需求 用 参与 者 ( 系统 的 用 户 ) 和 用 例 来 描述 。 用 例 定义 了 一 
个 或 多 个 参与 者 和 系统 之 间 的 交互 序列 。 在 需求 阶段 ， 用 例 模型 将 系统 考虑 成 黑 盒 ， 并 以 包含 
用 户 输入 和 系统 响应 的 叙述 形式 描述 参与 者 和 系统 之 间 的 交互 。 用 例 模 型 用 参与 者 和 用 例 描述 
系统 的 功能 性 需求 。 系 统 被 看 作 黑 盒 ， 即 处 理 系 统 会 做 什么 来 响应 参与 者 的 输入 ， 而 不 是 系统 
如 何 做 的 内 部 细节 。 在 后 续 的 分 析 建 模 ( 见 第 8 章 ) 期 间 ， 会 确定 参与 每 个 用 例 的 对 象 。 

用 例 总 是 从 参与 者 的 输入 开始 。 典 型 地 ， 一 个 用 例 包 含 了 参与 者 和 系统 之 间 的 交互 序列 。 每 
个 交互 由 参与 者 的 输入 以 及 后 续 的 系统 响应 组 成 。 因 此 ， 参 与 者 向 系统 提供 输入 ， 而 系统 向 参与 
者 提供 响应 。 系 统 总 是 被 考虑 为 一 个 黑 盒 ， 使 得 其 内 部 细节 不 会 暴露 。 尽 管 一 个 简单 的 用 例 可 能 
只 包含 参与 者 和 系统 之 间 的 一 个 交互 ， 但 一 个 更 典型 的 用 例会 由 参与 者 和 系统 之 间 的 多 个 交互 组 
成 。 更 复杂 的 用 例 也 可 能 会 涉及 不 止 一 位 参与 者 。 

举 一 个 简单 的 银行 系统 的 例子 ， 自 动 提 款 机 
(АТМ) 允许 客户 从 他 们 的 银行 账户 中 取款 。 这 里 
有 一 个 参与 者 “ATM 客户 ”( ATM Customer ) 和 一 T > 
AS FA fail “ВС” (Withdraw Funds )， 如 图 6-1 fir as. 


ATM Customer 


“取款 ”用 例 描述 了 客户 和 系统 之 间 的 交互 序列 。 用 
客户 响应 系统 提示 输入 密码 (PIN )， 最 终 客户 收 到 
ATM 机 发 出 的 现金 。 


一 个 简单 的 用 例 


考虑 “应 急 监控 系统 ”( Emergency Monitoring System ) 中 的 “查看 警报 ”( View Alarms ) 
作为 一 个 非常 简单 的 用 例 示 例 。 其 中 有 一 个 参与 者 ， 即 “监控 操作 员 ”( Monitoring Operator )， 
他 能 请 求 查 看 所 有 警报 的 状态 。 该 用 例 描述 的 关键 部 分 由 以 下 内 容 组 成 : 
用 例 的 名 称 : 查看 警报 。 
• 参与 者 的 名 称 : 监控 操作 员 。 
e 一 句 话 的 用 例 概 要 : 给 出 简要 描述 。 
ө 对 事件 主 序列 的 描述 。 对 该 用 例 而 言 ， 第 一 步 是 操作 员 请 求 ， 第 二 步 是 系统 响应 。 
ө 对 主 序列 的 蔡 代 情 况 的 描述 。 对 该 用 例 而 言 ， 在 第 二 步 会 有 一 个 替代 : 如 果 出 现 监控 
紧急 状况 则 该 蔡 代 会 被 执行 。 


用 例 名 称 : 查看 警报 
概要 : 监控 操作 员 查 看 未 解决 的 警报 。 
参与 者 : 监控 操作 员 
主 序列 : 
1. 监控 操作 员 请 求 查看 未 解决 的 警报 。 


2. 系统 显示 未 解决 的 警报 。 对 于 每 个 警报 ， 系 统 显 示警 报 的 名 称 、 警 报 描述 、 
警报 位 置 和 警报 严重 性 【高 、 中 、 低 )。 
可 替换 序列 : 
第 2 步 : 紧急 情况 。 系 统 向 操作 员 显示 紧急 警告 消息 。 
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6.5 节 给 出 了 一 种 更 全 面 的 文档 化 用 例 描述 的 方法 ; 6.6 节 表 述 了 一 个 更 详细 的 示例 。 
( 即 在 系统 之 外 ) (Rumbaugh et al. 2005 )。 在 用 ~ 
例 模型 中 ， 参 与 者 是 与 系统 交互 的 唯一 外 部 实 。 Moo" Operator 


6.3 ”参与 者 
Ж; 换 句 话说 ,参与 者 是 在 系统 之 外 的 ， 不 是 系 


参与 者 描绘 了 一 个 与 系统 交互 的 外 部 用 户 р. 
统 的 一 部 分 。 图 6-2 一 个 简单 用 例 的 示例 





6.31 参与 者 、 角 色 和 用 户 


参与 者 代表 了 在 应 用 领域 中 扮演 的 一 种 角色 ; 典型 地 ， 该 角色 是 人 类 用 户 扮 演 的 。 用 户 
是 一 个 个 体 ， 而 参与 者 代表 了 相同 类 型 的 所 有 用 户 所 扮演 的 角色 。 例 如 ,， “银行 系统 ”中 有 多 
位 客户 ， 他 们 都 由 参与 者 ATM Customer 来 代表 。 因 此 ， 参 与 者 ATM Customer 是 对 一 种 用 户 
类 型 的 建 模 ; 单个 的 客户 是 该 参与 者 的 实例 。 

参与 者 常常 是 人 类 用 户 。 因 为 这 个 原因 ， 在 UML 中 ， 参 与 者 用 人 形 图 标 来 表示 。 在 许多 
信息 系统 中 ， 人 是 唯一 的 参与 者 。 但 在 其 他 系统 中 ， 会 有 其 他 类 型 的 参与 者 作为 人 类 参与 者 的 
补充 或 者 替代 。 因 此 ， 参 与 者 可 能 是 一 个 和 本 系统 通过 接口 连接 的 外 部 系统 。 在 某 些 应 用 中 ， 
参与 者 还 可 以 是 外 部 输入 输出 (IO ) 设备 或 计时 器 。 外 部 IO ATT AT пи SA EAT ИК 
入 式 系统 中 非常 普遍 ; 在 这 些 系 统 中 ， 本 系统 通过 传感器 和 执行 器 与 外 部 环境 进行 交互 。 


6.3.2 ”主要 和 次 要 参与 者 


主要 参与 者 启动 用 例 。 因 此 ， 用 例 始 于 来 自主 要 参与 者 的 输入 ， 系 统 必须 响应 主要 参与 
者 。 其 他 参与 者 称 为 次 要 参与 者 ， 可 以 参与 到 用 例 中 。 一 个 用 例 中 的 主要 参与 者 可 以 是 另 一 个 
用 例 中 的 次 要 参与 者 。 至 少 有 一 个 参与 者 必须 从 用 例 中 获得 价值 ; 通常 ， 这 就 是 主要 参与 者 。 

主要 参与 者 和 次 要 参与 者 的 示例 如 图 6-3 所 示 。 参 与 者 “远程 系统 ”( Remote System ) 
启动 “生成 监控 数据 ”( Generate Monitoring Data) 用 例 ， 该 用 例 中 远程 系统 发 送 监 控 数 据 ， 
向 监控 操作 员 显 示 。 在 该 用 例 中 ,“ 远 程 系统 ”是 主要 参与 者 ， 它 启动 了 用 例 ;“ 监 控 操 作 员 ” 
(Monitoring Operator ) 是 次 要 参与 者 ， 它 接收 监控 数据 ， 并 因此 从 该 用 例 中 获得 价值 。 


=> 












«external system actor» 


А 


Remote System 


(主要 参与 者 ) 


«human actor» 


А 


Monitoring Operator 
( 次 要 参与 者 ) 


Data 


图 6-3 主要 参与 者 和 次 要 参与 者 以 及 外 部 系统 参与 者 的 示例 
6.33 ”对 参与 者 建 模 


人 类 参与 者 通常 使 用 多 种 IO 设备 与 系统 进行 物理 交互 。 人 类 参与 者 通过 标准 的 IO 设 
备 频繁 地 与 系统 交互 ， 例 如 键盘 、 显 示 器 或 鼠标 。 然 而 ， 在 某 些 情况 中 ， 人 类 参与 者 也 会 通 
过 非 标准 的 IO 设备 与 系统 交互 ， 如 各 种 各 样 的 传感器 。 所 有 这 些 情况 中 ， 人 是 参与 者 ，LIO 
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设备 不 是 参与 者 。 因 此 ， 参 与 者 是 终端 用 户 。 

考虑 人 类 参与 者 的 一 些 例子 。 在 “应 急 响 应 系统 ”中 ,通过 标准 IO 设备 和 系统 交互 的 “监控 
操作 员 ” 是 参与 者 的 例子 ， 如 图 6-2 所 示 。 男 一 个 人 类 参与 者 的 例子 是 АТМ 客户 (图 6G-1 )， 他 通过 
多 种 IO 设备 与 “银行 系统 ”交互 ， 包 括 读 卡 器 、 吐 钞 器 和 赁 条 打印 机 ， 另 外 还 有 键盘 和 显示 髓 。 










«human actom 


А 


Monitoring Operator 


( 次 要 参与 者 ) 










«human actom 


А 


User 


参与 者 也 可 以 是 外 部 系统 参与 者 ， 或 者 启动 ( 作为 主要 参与 者 ) 或 者 参与 ( 作为 次 要 参 
与 者 ) 用 例 。 外 部 参与 者 的 一 个 例子 是 “应 急 监控 系统 ”中 的 “远程 系统 "。“ 远 程 系统 ” 启 
动 “生成 监控 数据 ”( Generate Monitoring Data) 用 例 ， 如 图 6-3 所 示 。 远 程 系统 发 送 要 显示 

在 某 些 情形 下 ， 参 与 者 可 以 是 输入 设备 参与 者 或 者 输入 / 输出 设备 参与 者 。 当 用 例 中 没 
有 人 的 参与 、 向 系统 提供 外 部 输入 的 参与 者 是 输入 设备 或 IO 设备 时 ， 这 种 情况 就 会 发 生 。 
典型 地 ， 输 入 设备 参与 者 通过 传感器 与 
是 “监控 传感器 ”( Monitoring Sensor ), 7 a 
Е “ERZ JR” (Generate Alarm) ЈЕ a т 
例 提供 传感器 输入 ， 如 图 6-4 所 示 。 “We Monitoring Sensor 
用 例 中 也 是 次 要 参与 者 。 图 6-4 输入 设备 参与 者 的 示例 

参与 者 也 可 以 是 计时 器 参与 者 ， 周 
期 性 地 向 系统 发 送 定时 事件 。 当 系统 需要 定期 地 输出 某 些 信息 时 ， 就 需要 周期 性 用 例 。 图 6-5 
( Display Daily Report) 用 例 ， 该 用 例 周期 性 地 ( 例如， 每 天 中 午 ) 准备 一 份 每 日 报告 并 将 其 显示 
给 用 户 。 在 这 个 例子 中 ， 计 时 器 是 主要 参与 
者 ， 用 户 是 次 要 参与 者 。 在 计时 器 是 主要 参 。 aneuuan [ss | 

如 果 一 个 人 类 用 户 可 能 会 扮演 两 个 вероп Timer 
或 两 个 以 上 独立 的 角色 ， 则 每 个 角色 由。 全 要 参与 者 ) ( 次 要 参与 者 ) 
户 可 能 在 不 同 的 时 间 会 扮演 “ATM 操作 
员 ”( АТМ Operator ) 角色 ( 当 向 ATM 机 现金 吐 钞 器 中 补充 现金 时 ) Al “АТМ 客户 ”( ATM 
Customer ) 角色 ( 当 取 现金 时 )， 于 是 会 被 建 模 为 两 个 参与 者 。 

色 ， 但 其 他 的 角色 却 不 相同 。 在 这 种 情况 下 ， 这 些 参 与 者 

能 被 泛 化 ， 使 得 他 们 角色 中 的 公共 部 分 能 被 捕获 为 泛 化 的 с 
参与 者 ， 而 不 同 的 部 分 则 作为 特 化 的 参与 者 。 例 如 “应 急 
传感器 并 向 系统 发 送 传感器 数据 和 警报 。 这 种 相似 的 行为 
可 以 被 建 模 为 一 个 泛 化 的 参与 者 ， 即 “远程 传感器 "， 它 代 

表 了 这 个 公共 的 角色 (Вр, 两 个 特 化 参与 者 的 公共 的 行为 )， Monitoring Sensor Remote System 


给 监控 操作 员 的 监控 数据 。 
系统 交互 。 输 入 设备 参与 者 的 一 个 例子 «ари device actor» 
控 操 作 员 ”( Monitoring Operator) 在 该 290 = 
给 出 了 计时 器 参与 者 的 一 个 例子 。“ 报 告 计 时 器 ”( Report Timer) 参与 者 启动 “显示 每 日 报告 ” 
与 者 的 用 例 中 ,通常 是 次 要 参与 者 ( 本 例 中 + 
不 同 的 参与 者 来 表示 。 例 如 ， 同 样 的 用 图 6-5 计时 器 参与 者 的 示例 
在 某 些 系统 中 ， 不 同 的 参与 者 可 能 拥有 一 些 公共 的 角 ү 
响应 系统 ”( 第 23 章 )， 其 中 的 两 个 参与 者 “监控 传感器 ” 
参与 者 和 “远程 系统 ”参与 者 行为 相似 ， 都 是 监控 远程 
如 图 6-6 所 示 。 图 6-6 参与 者 的 泛 化 和 特 化 
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有 了 时候 并 不 明确 谁 是 参与 者 。 实 际 上 ， 最 先 的 评估 可 能 是 不 正确 的 。 例 如 ， 在 报告 失窃 
卡片 的 用 例 中 ， 用 户 参与 者 电话 告知 银行 他 的 АТМ ЕЛИ Г. ХН БАЛЕТ ЕРЕ 5 
者 。 然 而 ， 如 果 客 户 实际 上 是 通过 电话 向 银行 职员 告知 ， 而 银行 职员 实际 上 将 信息 录入 系统 ， 
那么 银行 职员 才 是 参与 者 。 


6.4 标识 用 例 


为 了 确定 系统 中 的 用 例 ， 从 考虑 参与 者 及 其 与 系统 间 的 交互 开始 是 有 用 的 。 每 个 用 
例 描述 了 参与 者 和 系统 之 间 的 交互 序列 。 用 这 种 方法 ， 系 统 的 功能 性 需求 通过 用 例 来 描 
述 ， 用 例 构 建 了 系统 的 功能 规约 。 然 而 ， 当 开发 用 例 时 ， 重 要 的 是 避免 功能 分 解 。 在 功 
能 分 解 中 ， 多 个 小 的 用 例 描述 系统 的 单个 小 功能 ， 而 不 是 描述 对 参与 者 提供 有 用 结果 的 事件 
序列 。 

我 们 再 看 看 银行 系统 的 例子 。 除 了 从 АТМ 机 取款 之 外 ， 参 与 者 “ATM 客户 ”也 被 允许 查询 
账户 或 在 两 个 账户 间 转 账 。 由 于 这 些 是 由 客户 发 
起 的 带 来 不 同 有 用 结果 的 不 同 功能 ， 因 此 查询 和 
转账 功能 宜 被 建 模 为 分 离 的 用 例 ， 而 不 是 成 为 原 
始 用 例 的 一 部 分 。 这 样 ， 客 户 就 能 启动 三 个 用 例 
(如 图 6-7 ras): “ВО” (Withdraw Funds )、“ 查 大 
询 账 户 ”(Query Account) 和 “转账 ”(Transfer 
Fun ds a ATM Customer 

用 例 的 主 序列 描述 了 参与 者 和 系统 之 间 最 常 
见 的 交互 序列 。 用 例 的 主 序列 中 也 会 存在 分 支 来 
描述 参与 者 和 系统 之 间 不 那么 频繁 的 交互 。 这 些 
可 替换 序列 是 与 主 序列 偏离 的 ， 仅 仅 在 某 些 环境 
( 例如 参与 者 向 系统 进行 了 错误 的 输入 ) 下 才 执 
行 。 用 例 中 的 可 替换 序列 有 时 可 以 稍 后 和 主 序列 合并 起 来 ， 这 取决 于 应 用 需求 。 可 替换 序列 
也 在 用 例 中 描述 。 

在 “取款 ”用 例 中 ， 主 序列 是 成 功 取款 的 步骤 的 序列 。 可 替换 序列 用 来 说 明 各 种 错误 情 
况 ， 如 当 客 户 输入 错误 的 PIN 码 时 必须 提示 ，ATM 卡 未 被 识别 或 已 挂失 ， 等 等 。 

用 例 中 的 每 个 序列 称 作 场 景 。 一 个 用 例 通 常 描述 了 多 个 场景 : 一 个 主 序列 和 多 个 可 替换 
序列 。 请 注意 ,场景 是 用 例 中 一 个 完整 的 序列 ， 因 此 场景 可 以 始 于 执行 主 序列 ， 然 后 在 决策 
点 接 上 一 个 可 替换 分 支 。 例 如 , “取款 ”的 一 个 场景 开始 于 主 序列 中 客户 将 АТМ 卡 插 人 读 卡 
器 ， 看 到 提示 后 输入 PIN 码 ， 但 是 收 到 了 一 条 错误 消息 ， 因 为 PIN 码 是 错误 的 ， 接 着 再 输入 
正确 的 PIN 码 。 


Transfer Funds 


图 6-7 “银行 系统 ”的 参与 者 和 用 例 


6.5 用例 模型 中 文档 化 用 例 
用 例 模型 中 的 每 个 用 例 都 采用 用 例 描述 来 文档 化 ， 如 下 所 示 : 
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AAR: 每 个 用 例 都 给 予 一 个 名 字 。 

概述 : 用 例 的 简短 描述 ， 一 般 是 一 两 名 话 。 

依赖 : 这 个 可 选 的 部 分 描述 了 该 用 例 是 否 依赖 其 他 用 例 ， 即 它 是 否 包含 或 扩展 另 一 
个 用 例 。 

参与 者 : 该 部 分 给 用 例 中 的 参与 者 命名 。 总 是 有 一 个 主要 参与 者 来 启动 用 例 。 男 外 ， 
可 以 有 次 要 参与 者 也 参与 到 用 例 中 。 例如， 在 “取款 ”用 例 中 ,“ATM 客户 ”是 唯一 的 参 
与 者 。 

前 置 条 件 : 从 该 用 例 的 角度 在 用 例 开始 时 必须 为 真 的 一 个 或 多 个 条 件 。 例 如 ，ATM 
机 是 空闲 状态 ， 屏 幕 显示 “欢迎 ”消息 。 

主 序列 描述 : 用 例 的 主体 是 对 该 用 例 主 序列 的 叙述 性 描述 ， 这 是 参与 者 和 系统 之 间 
最 经 常 的 交互 序列 。 该 描述 的 形式 是 参与 者 的 输入 ， 接 着 是 系统 的 响应 。 

可 替换 序列 描述 : 主 序列 的 可 替换 分 支 的 叙述 性 描述 。 主 序列 可 能 有 多 个 可 蔡 换 分 
支 。 例 如 ， 如 果 客 户 的 账户 没有 足够 的 资金 ， 则 显示 抱歉 并 退出 卡片 。 在 给 出 可 替换 描述 
的 同时 ， 用 例 中 可 替换 序列 从 主 序列 分 支出 来 的 这 个 步骤 也 被 标识 出 来 。 

非 功能 性 需求 : 非 功能 性 需求 的 叙述 性 描述 ,例如 性 能 和 安全 性 需求 。 

后 置 条 件 : 该 用 例 终点 处 ( 从 该 用 例 的 角度 来 看 ) 总 是 为 真 的 条 件 ， 如 果 遵 循 了 主 
序列 的 话 。 例 如 ， 客 户 的 资金 已 经 被 取出 。 

未 解决 的 问题 : 在 开发 期 间 ， 有 关 用 例 的 问题 被 记录 下 来 ， 用 于 和 用 户 进行 讨论 。 





66 用例 描 述 示例 


本 小 节 给 出 了 一 个 用 例 示例 :“ 下 单 请 求 ”( Make 
Order Request )， 它 是 “在 线 购 物 系 统 ” 的 用 例 之 一 。 
图 6-8 展示 了 “在 线 购物 系统 ”中 由 客户 启动 的 用 例 
的 用 例 图 。 其 中 有 一 个 参与 者 “客户 ”( Customer ) 
( 他 浏览 商品 目录 并 请 求购 买 商品 ) 以 及 由 该 参与 者 1 
启动 的 三 个 用 例 ， 分 别 是 “浏览 商品 目录 ”( Browse 
Catalog ) ( 浏览 商品 目录 并 选择 商品 )、“ 下 单 请 求 ” Customer 
(为 了 购买 而 提供 账户 和 信用 卡 信息 ) 和 “查看 订单 ” 

( View Order ) (查看 订单 的 状态 )。 在 “下 单 请 求 ” 用 

例 的 主 序 列 中 ， 客 户 下 单 购买 网 上 商品 目录 中 的 商品 

并 有 足够 的 信用 为 商品 付款 。 可 替换 序列 处 理 其 他 不 

常 出 现 的 情况 : 客户 没有 账号 需要 去 注册 一 个 账号 ， 图 6-8 “在 线 购 物 系统 ”的 参与 者 和 用 例 
或 者 客户 有 一 张 无 效 的 信用 卡 。 






Browse Catalog 
Make Order 
Request 


View 
Order Status 










用 例 名 称 : 下 单 请 求 
概述 : 客户 下 单 从 在 线 购物 系统 中 购买 商品 。 客 户 的 信用 卡 要 验证 有 足够 信用 为 所 
要 购买 的 目录 商品 付款 。 


参与 者 : 客户 
前 置 条 件 : 客户 已 选择 一 个 或 多 个 目录 商品 。 
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主 序列 : | 
1. 客户 提出 订单 请 求 和 客户 账户 ID 来 为 购买 付款 。 
2. 系统 检索 客户 账户 信息 ， 包 括 该 客户 的 信用 卡 详细 信息 。 
3. 系统 针对 购买 价格 检查 客户 的 信用 卡 ， 并 创建 信用 卡 购 买 授权 号 码 〈 如 果 检 查 通过 ), 
4. 系统 创建 发 货 单 ， 包 含 订单 明细 、 客 户 ID 和 信用 卡 授权 号 码 。 
5. 系统 确认 批准 购买 ， 并 向 客户 显示 订单 信息 。 


可 替换 序列 : 

第 2 步 : 如 果 客户 没有 账号 ， 则 系统 为 其 创建 一 个 账号 。 

第 3 步 : 如 果 客 户 的 信用 卡 请 求 被 拒绝 ， 则 系统 提示 客户 输入 不 同 的 信用 卡号 码 。 
客户 可 以 输入 一 个 不 同 的 信用 卡号 码 或 取消 订单 。 

后 置 条 件 : 系统 为 客户 创建 了 发 货 单 。 


67 ”用例 关系 


当 用 例 变 得 非常 复杂 时 ， 用 例 之 间 的 依赖 可 以 用 包含 (include) 和 扩展 (extend) 关系 
来 定义 ， 其 目的 是 使 可 扩展 性 最 大 化 和 复 用 用 例 。 包 含 用 例 ( inclusion use cases) 是 用 来 标识 
多 个 用 例 中 共同 的 交互 序列 ， 这 些 共 同 的 交互 序列 能 被 抽取 出 来 和 复 用 。 

UML 提供 的 男 一 个 用 例 关系 是 用 例 泛 化 。 用 例 泛 化 (use case generalization) 与 扩展 关 
系 相 似 ， 因 为 它 也 是 用 来 描述 变化 性 的 。 然 而 ， 用 户 经 常 觉 得 用 例 泛 化 的 概念 很 含糊 ， 因 此 
在 COMET 方法 中 ， 泛 化 的 概念 局 限于 类 。 扩 展 关系 足以 处 理 用 例 的 变化 性 。 


68 包含 关系 


在 应 用 的 用 例 首 次 开发 之 后 ， 有 时 就 能 确定 参与 者 和 系统 之 间 的 共同 交互 序列 ， 它 们 
横 跨 了 多 个 用 例 。 这 些 共 同 交互 序列 反映 了 多 个 用 例 之 间 共 同 的 功能 。 一 个 共同 交互 序列 
可 以 从 多 个 原始 的 用 例 中 抽取 出 来 ， 并 形成 一 个 新 的 用 例 ， 称 作 包 含 用 例 。 包 含 用 例 通常 
是 抽象 的 ， 即 它 不 能 够 独立 执行 。 一 个 抽象 用 例 必须 作为 一 个 具体 〈 即 可 执行 ) 用 例 的 一 部 
分 来 执行 。 

当 共同 的 功能 分 离 到 包含 用 例 中 时 ， 该 用 例 就 能 被 其 他 用 例 复 用 。 然 后 就 有 可 能 定义 旧 
用 例 的 一 个 更 简洁 的 版 本 ， 该 版 本 移 除了 共同 交互 序列 。 旧 用 例 的 这 个 简洁 的 版 本 被 称 作 基 
用 例 (或 具体 用 例 )， 它 包含 了 包含 用 例 。 

包含 用 例 总 是 反映 了 多 个 用 例 之 间 共 同 的 功能 。 当 共同 的 功能 分 离 到 包含 用 例 中 时 ， 该 
包含 用 例 就 能 被 多 个 基 用 例 〈 可 执行 的 用 例 ) 复 用 。 通 常 只 有 在 初始 迭代 中 已 经 开发 了 多 个 
用 例 之 后 才能 开发 包含 用 例 。 只 有 在 这 时 ， 重复 的 交互 序列 才能 被 发 现 ， 来 形成 包含 用 例 的 
基础 部 分 。 

包含 用 例 是 和 基 用 例 联合 起 来 执行 的 ， 基 用 例 包含 并 执行 包含 用 例 。 在 编程 术语 中 ， 包 
含 用 例 类 似 于 库 例 程 ， 而 基 用 例 则 类 似 于 调用 库 例 程 的 程序 。 

包含 用 例 可 以 没有 特定 的 参与 者 。 实 际 上 ， 参 与 者 是 包含 了 包含 用 例 的 基 用 例 的 参与 者 。 
因为 不 同 的 基 用 例 都 会 使 用 包含 用 例 ， 所 以 包含 用 例 可 能 会 被 不 同 的 参与 者 使 用 。 
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6.81 包含 关系 和 包含 用 例 示 例 


考虑 “银行 系统 ”( 见 第 21 章 的 “银行 系统 ”案例 研究 ) 作为 包含 用 例 的 例子 ， 其 中 
有 一 个 参与 者 “ATM 客户 ”(ATM Customer )。 系 统 的 初始 分 析 标 识 了 三 个 用 例 :“ 取 款 ” 
( Withdraw Funds ) “查询 账户 ”( Query Account) 和 “转账 ”( Transfer Funds )。 这 三 个 用 例 
是 由 该 参与 者 启动 的 主要 功能 。 在 “取款 ”用 例 中 ， 主 序列 包含 了 读 АТМ Е. 、 验 证 客户 的 密 
码 、 检 查 客户 在 所 请 求 的 账户 中 有 足够 的 资金 ， 接 着 ， 如 果 验 证 成 功 ， 则 发 出 现金 、 打 印 赁 
条 并 退出 卡片 。 对 这 三 个 用 例 进 一 步 分 析 会 发 现 每 个 用 例 的 第 一 个 部 分 ， 即 读 ATM 卡 和 验证 
客户 的 密码 是 相同 的 。 在 每 个 用 例 中 重复 该 序列 没有 好 处 ， 因 此 ， 将 PIN 码 验证 这 一 序列 分 
离 成 一 个 单独 的 包含 用 例 ， 称 作 “ 验 证 PIN 码 ”( Validate PIN )， 这 个 用 例 可 以 被 (修改 后 的 ) 
“取款 ”“ 查 询 账户 ”和 “转账 ”用 例 使 用 。 该 示例 的 用 例 图 如 图 6-9 所 示 。 两 种 类 型 的 用 例 
之 间 的 关系 是 包含 关系 ;“ 取 款 ”"“ 查 询 账户 ”和 “转账 ”用 例 包 含 了 “验证 PIN 码 ” 用 例 。 


Validate PIN 
> 
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| 
Р ! ~ 
А „ А А 
«include» Pig { «include» 、~、 «include» 
~ 
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2 


~ 
2 ~ 
© s “ы 
Withdraw Transfer 
Р" 





ATM Customer 


[ 83 | 图 6-9 包含 用 例 和 包含 关系 的 示例 


包含 用 例 “ 验 证 PIN 码 ” 和 包括 “验证 PIN 码 ” 用 例 的 基 用 例 “ 取 款 ” 的 用 例 描 述 的 主 
要 部 分 如 下 : 


包含 用 例 “ 验 证 PIN 码 ” 


用 例 名 称 : 验证 PING 
概述 : 系统 验证 客户 РМ 码 。 
参与 者 : ATM 客户 
前 置 条 件 : АТМ И, 显示 “欢迎 ”消息 。 
主 序列 : 
. 客户 向 读 卡 器 中 插入 АТМ 卡 。 
.如果 系统 识别 了 该 卡 ， 则 读 取 卡号 。 
. 系统 提示 客户 输入 PIN 码 。 
. 客户 输入 PIN 码 。 
.系统 检查 该 卡 的 有 效 期 以 及 是 否 已 经 报告 丢失 或 遭 宅 。 
. 如 果 卡 是 有 效 的 ， 则 系统 检查 用 户 输入 的 PIN 码 是 否 和 系统 存储 的 卡 PIN SLR. 
. 如 果 PIN 码 数字 匹配 ， 则 系统 检查 该 АТМ 卡 可 访问 哪些 账户 。 
8. 系统 显示 客户 账号 并 提示 客户 交易 类 型 : 取款 、 查 询 或 转账 。 
可 替换 序列 : ( 可 替换 描述 见 第 21 Ж) 
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基 用 例 “ 取 款 ” 


ВИА: 取款 
概述 : 客户 从 有 效 的 银行 账户 提取 特定 数量 的 钱 款 。 
参与 者 : ATM 客户 
依赖 : 包含 “验证 PIN 码 ” 用 例 。 
前 置 条 件 : АТМ М, Еж “ЖИ” ЖЕ. 
主 序列 : 
1. 包含 “验证 PIN 码 ” 用 例 
2. 客户 选择 取款 
3.( 之 后 的 取款 描述 见 第 21 章 ) 


6.8.2 ”结构 化 元 长 的 用 例 


包含 关系 也 能 够 用 来 组 织 一 个 宛 长 的 用 例 。 基 用 例 提供 参与 者 和 系统 之 间 高 层次 
的 交互 序列 。 包 含 用 例 提供 参与 者 和 系统 之 间 低 层次 的 交互 序列 。“ 制 造 高 容量 部 件 ” 
( Manufacture High-Volume Part) 用 例 ( 图 6-10) 就 是 这 样 一 个 例子 ， 它 描述 了 制造 一 个 
部 件 的 交互 序列 。 该 过 程 包含 了 接收 生产 该 部 件 的 原材料 (在 “接收 部 件 ”( Receive Part ) 
用 例 中 描述 )， 在 每 个 工厂 工作 站 执行 生产 步骤 (在 “在 高 容量 工作 站 处 理 部 件 ”( Process 
Part at High-Volume Workstation ) 用 例 中 描述 ) 和 运输 已 生产 的 部 件 (在 “运输 部 件 ”( Ship 


Part ) 用 例 中 描述 )。 
Process Part at . 
Receive Part High-Volume Ship Part 
Workstation 
д А 
~ 
~ 
~ 
~ 






ГА 
| 7 
| z 
1 / 
1 «include» 7 
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«include» м «include» 
1 
! Pick & Place 


Robot 
Manufacture Š 


High-Volume 


图 6-10 多 个 包含 用 例 和 包含 关系 的 示例 


Production 
Manager 
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Robot 


69 扩展 关系 


在 某 些 情形 下 ， 一 个 用 例 可 能 会 非常 复杂 ， 有 许多 可 替换 的 分 支 。 扩 展 关系 用 来 对 用 例 
可 能 采取 的 可 替换 路 径 进行 建 模 。 如 果 一 个 用 例 有 太 多 可 替换 的 、 可 选 的 和 异常 的 交互 序列 ， 
那么 它 可 能 会 变 得 非常 复杂 。 针 对 该 问题 的 一 个 解决 方案 是 将 可 替换 或 可 选 的 交互 序列 分 离 
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成 单独 的 用 例 。 该 新 用 例 的 目的 是 扩展 旧 的 用 例 ( 如 果 保 持 合适 的 条 件 )。 被 扩展 的 用 例 称 作 
基 用 例 ， 用 来 进行 扩展 的 用 例 称 作 扩展 用 例 。 

在 某 些 条 件 下 ， 基 用 例 能 通过 在 扩展 用 例 中 给 出 的 描述 进行 扩展 。 根 据 哪 个 条 件 为 真 ， 
基 用 例 能 以 不 同 的 方式 进行 扩展 。 扩 展 关系 可 用 于 以 下 情况 : 

© 展示 基 用 例 只 在 某 些 环境 下 执行 的 有 条 件 的 部 分 

e 对 复杂 或 可 替换 的 路 径 建 模 

特别 要 注意 ,一 方面 ， 基 用 例 不 依赖 于 扩展 用 例 。 男 一 方面 ， 扩 展 用 例 依赖 于 基 用 例 并 

[85] 只 在 基 用 例 中 引起 它 执行 的 条 件 为 真 时 才 执 行 。 尽 管 一 个 扩展 用 例 通 常 只 扩展 一 个 基 用 例 ， 

但 它 扩展 一 个 以 上 的 用 例 也 是 可 能 的 。 一 个 基 用 例 能 够 被 多 个 扩展 用 例 扩展 。 


6.9.1 扩展 点 


扩展 点 是 用 来 规定 基 用 例 中 能 被 增加 扩展 的 精确 位 置 。 一 个 扩展 用 例 只 可 以 在 这 些 扩展 
点 上 扩展 基 用 例 (Fowler 2004; Rumbaugh el al. 2005 )。 

每 个 扩展 点 都 被 赋予 了 一 个 名 称 。 扩 展 用 例 对 于 扩展 点 有 一 个 插入 片段 ， 该 片段 在 其 基 
用 例 中 扩展 点 的 位 置 处 插入 。 扩 展 关 系 可 以 是 有 条 件 的 ， 这 意味 着 可 以 定义 一 个 条 件 ， 该 条 
件 必须 为 真 时 才 调 用 扩展 用 例 。 这 样 ， 就 可 能 在 同一 个 扩展 点 上 有 多 个 扩展 用 例 ， 但 每 个 扩 
展 用 例 都 满足 不 同 的 条 件 。 

片段 定义 了 在 达到 扩展 点 时 所 执行 的 行为 片段 。 当 用 例 的 一 个 实例 被 执行 并 到 达 了 基 用 
例 中 的 扩展 点 时 ， 如 果 条 件 满足 ， 则 用 例 的 执行 将 转移 到 扩展 用 例 中 的 相应 片段 。 在 片段 完 
成 后 ， 执 行 再 转移 回 基 用 例 。 

带 着 多 个 扩展 用 例 的 扩展 点 可 用 于 对 多 个 可 替换 情况 建 模 ， 其 中 每 个 扩展 用 例 规定 了 一 
个 不 同 的 可 替换 。 要 设计 扩展 条 件 ， 使 得 在 任何 给 定 的 情况 下 只 有 一 个 条 件 能 为 真 ， 这 样 就 
只 有 一 个 扩展 用 例会 被 选择 。 

扩展 条 件 的 值 在 用 例 的 运行 时 执行 期 间 被 设置 ， 这 是 因为 在 任何 一 次 中 只 能 选择 一 个 扩 
展 用 例 ， 而 在 另 一 次 中 则 可 以 选择 一 个 可 替换 的 扩展 用 例 。 换 句 话 说， 扩展 条 件 是 在 用 例 的 
运行 时 设 定 和 更 改 的 。 

虽然 扩展 用 例 可 以 在 多 个 扩展 点 扩展 一 个 用 例 ， 但 这 种 方法 只 在 扩展 点 扩展 与 扩展 用 例 
扩展 相等 价 时 才 推 荐 。 尤 其 是 ， 在 一 个 扩展 用 例 中 使 用 多 个 插入 片段 是 有 技巧 的 ， 因 此 也 被 
认为 是 易于 出 错 的 。 


6.9.2 扩展 点 和 扩展 用 例 示例 


考虑 下 面 这 个 超市 系统 (图 6-11 ) 的 例子 。 在 基 用 例 “ 顾 客 结账 ”( Checkout Customer ) 
中 声明 一 个 名 为 “付款 ”( Payment ) 的 扩展 点 。 基 用 例 处 理 顾 客 结账 。 三 个 扩展 用 例 处 理 付 
款 类 型 :“ 现 金 结 账 ”( Рау by Cash )、“ 信 用 卡 结账 ”( Рау by Credit Card) 和 “ 借 记 卡 结账 ” 
(Рау by Debit Card )。 为 每 个 扩展 用 例 提供 一 个 选择 条 件 。 扩 展 关 系 使 用 扩展 点 名 称 和 选择 条 
件 来 标注 。 例 如 , «extend» ( 付款 ) [ 现金 付款 ]， 如 图 6-11 所 示 。 互 斥 的 选择 条 件 分 别 是 [ 现 
金 付款 ]、[ 信用 卡 付款 ] 和 [ 借 记 卡 付款 ]。 用 例 执行 期 间 ， 取 决 于 客户 选择 如 何 付款 ， 合 适 
[86] 的 选择 条 件 会 置 为 真 。 
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图 6-11 扩展 关系 和 扩展 用 例 的 示例 


BAG) “顾客 结账 ” 


ABAR: 顾客 结账 
概述 : 系统 为 顾客 结账 。 
参与 者 : 顾客 
前 置 条 件 : AKEZA, 显示 “欢迎 ”消息 。 
主 序列 : 
1. 顾客 扫描 所 选 的 商品 。 
2. 系统 显示 商品 名 称 、 价 格 和 累计 总 价 。 
3. 对 每 一 项 购买 的 商品 ， 顾 客 重复 步骤 1 和 2。 
4. 顾客 选择 付款 方式 。 
5. 系统 提示 现金 付款 、 信 用 卡 付款 或 借 记 卡 付 款 。 
6.« 付款 》 
7. 系统 屏幕 显示 “谢谢 ”。 





在 该 基 用 例 的 描述 中 , 第 6 步 « 付款 » 是 一 个 占 位 符 , 标识 了 有 个 合适 的 扩展 用 例 在 此 
执行 。 对 于 扩展 用 例 “ 现 金 结账 *"， 扩 展 条 件 是 称 作 [现金 付款 ] 的 选择 条 件 。 当 条 件 [ 现金 
付款 ] 为 真 时 ， 该 扩展 用 例会 被 执行 。 


扩展 用 例 “ 现 金 结 账 ” 


用 例 名 称 : 现金 结账 

概述 : 顾客 为 购买 的 商品 使 用 现金 结账 。 
参与 者 : 顾客 

依赖 : 扩展 顾客 结账 


前 置 条 件 : 顾客 已 经 扫描 了 商品 ， 但 尚未 付款 。 
插入 片段 的 描述 : 
1. 顾客 选择 现金 付款 。 
2. 系统 提示 顾客 放 入 纸币 或 硬币 现金 。 
3. 客户 放 入 现金 。 [87 ] 
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4. 系统 计算 找 零 。 
5. 系统 显示 应 付款 总 额 、 现 金 付 款额 和 找 零 。 


6. 系统 在 收据 上 打印 应 付款 总 额 ， 现 金 付款 额 和 找 零 。 





对 于 扩展 用 例 “ 信 用 卡 结账 "， 选 择 条 件 是 称 为 [信用卡 付 款 ] ( 如 图 6-11 )。 当 条 件 [ 信 
用 卡 付款 ] 为 真 时 〈 即 用 户 选择 了 用 信用 卡 结账 )， 该 扩展 用 例会 被 执行 。 当 然 ， 如 果 用 户 选 
择 用 现金 结账 来 替代 ， 那 么 “现金 结账 ”用 例会 被 替代 执行 。 


扩展 用 例 “ 信 用 卡 结账 ” 
用 例 名 称 : 信用 卡 结账 
概述 : 顾客 为 购买 的 商品 用 信用 卡 结账 。 
参与 者 : 顾客 
依赖 : 扩展 顾客 结账 
前 置 条 件 : 顾客 已 经 扫描 了 商品 ,但 尚未 付款 。 
插入 片段 的 描述 : 
1. 顾客 选择 信用 卡 付款 。 
. 系统 提示 顾客 刷卡 。 
. 顾客 刷卡 。 
.系统 读 取 卡 的 ID 和 有 效 期 。 
.系统 将 交易 信息 发 送 到 授权 中 心 ， 包 含 卡 ID、 有 效 期 和 支付 金额 。 
6. 如 果 交 易 被 批准 ， 则 授权 中 心 返 回 肯定 的 确认 信息 。 
7. 系统 显示 支付 金额 和 确认 信息 。 
8. 系统 在 收据 上 打印 支付 金额 和 确认 信息 。 





扩展 用 例 “ 借 记 卡 结账 ”的 用 例 描述 以 相似 的 方式 处 理 ， 只 是 客户 仍 需 要 输入 PIN 码 。 
“ 借 记 卡 结账 ”有 一 个 选择 条 件 ， 称 作 [ 借 记 卡 付款 ]。 


6.10 用例 组 织 指南 


用 例 关系 的 小 心 应 用 有 助 于 用 例 模 型 的 总 体 组 织 ; 然而 ， 用 例 关 系 要 审慎 地 采用 。 要 注 

Ж, 不宜 采用 对 应 于 独立 功能 ( 例如 出 钞 、 打 印 回执 和 退 卡 ) 的 小 的 包含 用 例 。 这 些 功能 太 

小 了 ， 把 它们 从 用 例 中 分 离 出 来 会 导致 功能 分 解 ， 使 用 例 碎 片 化 。 这 些 碎片 化 用 例 的 用 例 描 

[88] 述 可 能 每 个 只 有 一 句 话 而 不 是 对 交互 序列 的 描述 ， 这 就 会 导致 一 个 过 度 复 杂 和 难以 理解 的 用 
例 模 型 ， 换 言 之 ， 只 见 树木 ( 独立 功能 ) 不 见 森 林 (整个 交互 序列 ) ! 


6.11 规定 非 功 能 性 需求 


非 功能 性 需求 可 以 用 用 例 描述 中 一 个 单独 的 部 分 来 规定 ， 这 与 规定 可 替换 序列 的 形式 基 
本 相同 。 例 如 ， 对 于 “验证 PIN 码 ” 用 例 ， 可 能 有 一 个 安全 需求 : 卡号 和 PIN 码 都 必须 被 加 
密 。 也 可 能 有 一 个 性 能 需求 : 系统 必须 在 5 秒 内 响应 参与 者 的 输入 。 如 果 非 功能 性 需求 应 用 
到 一 组 相关 的 用 例 ， 那么 它们 也 能 同样 被 文档 化 ， 如 下 一 小 节 所 述 。 
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非 功能 性 需求 可 以 用 用 例 描述 中 一 个 单独 的 部 分 来 规定 。 对 于 “验证 PIN 码 ” 用 例 , ЗЕ 
功能 性 需求 可 以 描述 如 下 : 


安全 需求 : 系统 应 加 密 ATM 卡号 和 PIN 码 。 


性 能 需求 : 系统 应 在 5 秒 内 响应 参与 者 的 输入 。 





6.12 AHE 


对 于 大 型 系统 ， 不 得 不 处 理 用 例 模型 中 的 大 量 用 例 经 常 是 很 难 操作 的 。 解 决 这 种 增 大 问 
题 的 一 个 好 的 方法 是 引入 用 例 包 ， 将 相关 的 用 例 分 组 到 一 起 。 这 样 ， 用 例 包 就 能 表示 那些 描 
述 系统 的 主要 功能 子 集 的 高 层次 需求 。 因 为 参与 者 经 常 启动 和 参与 相关 的 用 例 ， 所 以 用 例 也 
能 基于 使 用 它们 的 主要 参与 者 来 分 组 成 包 。 适 用 于 一 组 相关 用 例 的 非 功能 性 需求 可 以 分 配 到 
包含 这 些 用 例 的 用 例 包 中 。 

例如 ,“ 应 急 监控 系统 ”中 ， 系 统 的 主要 参与 者 是 “远程 传感器 ”( Remote Sensor), “W 
控 操 作 员 ”( Monitoring Operator ) 和 “应 急 管 理 员 ”( Emergency )， 每 一 个 都 启动 和 参与 多 个 
用 例 。 图 6-12 展示 了 应 急 监 控 系 统 中 用 例 包 的 例子 ， 名 为 “应 急 监控 用 例 包 ”( EmergencyM 
onitoringUseCasePackage )， 包 含 了 4 个 用 例 。“ 监 探 操作 员 ”是 用 例 “ 查 看 警报 ”和 “查看 监 
控 数据 ”的 主要 参与 者 ， 是 其 他 用 例 的 次 要 参与 者 。“ 远 程 传感器 ”是 “生成 警报 ”( Generate 
Alarm ) 用 例 和 “生成 监控 数据 ”( Generate Monitoring Data ) 用 例 的 主要 参与 者 。 


«use case package» 
EmergencyMonitoringUseCasePackage 












View Monitoring Data 
Generate Monitoring 
Data 
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Monitoring 


Operator 
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Remote Sensor 





Р 6-12 用例 包 的 示例 


6.13 活动 图 
活动 图 是 一 种 描述 控制 流 和 活动 中 序列 的 UML 图 。 活 动 图 显示 了 活动 序列 、 决 策 结 点 和 
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循环 ， 甚 至 还 有 并 发 活动 。 活 动 图 在 工作 流 建 模 中 被 广泛 使 用 ， 例 如 ， 在 面向 服务 的 应 用 中 。 

用 例 模型 也 能 使 用 活动 图 来 描述 。 然 而 ， 活 动 图 能 力 的 一 个 子 集 就 足以 描述 用 例 。 特 别 
地 ， 对 于 用 例 没 有 必要 对 并 发 活动 进行 建 模 。 

活动 图 可 用 来 表示 用 例 的 顺序 步 又 ， 包 括 
主 序列 和 所 有 的 可 替换 序列 。 活 动 图 可 用 于 为 
用 例 提供 更 精确 的 描述 ， 因 为 活动 图 会 明确 地 
显示 出 在 序列 中 的 哪里 以 及 可 替换 序列 有 哪个 
条 件 会 从 主 序列 中 偏离 出 来 。 活 动 结 点 可 用 来 
表示 该 用 例 的 一 个 或 多 个 顺序 步 怠 。 高 层 活动 
结 点 可 用 来 表示 一 个 用 例 ， 该 用 例 稍 后 可 被 分 
解 成 一 个 独立 的 活动 图 。 活 动 图 也 可 用 来 描绘 
用 例 中 的 顺序 。 

活动 图 使 用 活动 结 点 、 决 策 结 点 、 连 接 顺 
序 活动 结 点 的 弧 和 循环 来 描绘 用 例 。 活 动 结 点 
用 来 描绘 用 例 描 述 中 一 个 或 多 个 步骤。 决策 结 
点 用 来 描绘 基于 决策 结果 可 替换 序列 会 从 主 序 
列 中 分 支出 来 的 情况 。 取 决 于 用 例 ， 可 替换 序 
列 可 以 重新 合并 到 主 序列 中 ， 例 如 ， 循 环 回 到 
之 前 的 活动 结 点 或 者 之 后 重新 合并 到 主 序列 中 。 

活动 结 点 可 以 是 聚合 结 点 ， 能 层次 地 分 解 
以 给 出 低层 次 的 活动 图 。 此 概念 可 用 于 描绘 包 
含 用 例 和 扩展 用 例 。 因 此 ， 基 用 例 中 的 一 个 活 
动 结 点 可 用 来 表示 到 包含 (或 扩展 ) 用 例 的 一 
条 链接 ， 然 后 这 些 用 例 便 以 单独 的 较 低层 次 的 
活动 图 来 描绘 。 

图 6-13 给 出 了 活动 图 的 一 个 例子 ， 这 是 
“在 线 购物 系统 ”( 见 6.6 节 ) 的 “下 单 请 求 ” 用 
例 。 该 用 例 包含 了 一 个 主 序列 ， 其 中 顾客 提出 
下 单 请 求 来 购买 网 上 商品 目录 中 的 商品 ， 并 且 
有 足够 的 信用 为 商品 付款 。 可 替换 序列 是 为 了 
创建 一 个 新 的 顾客 账户 和 为 了 处 理 无 效 的 信用 卡 。 每 个 会 导致 可 替换 场景 的 决策 点 都 被 显 式 
地 描绘 出 来 。 在 这 个 示例 中 ,客户 输入 下 单 请 求 信 息 ， 系 统 获取 账户 信息 ( 带 有 一 个 创建 新 
账户 的 可 替换 序列 )， 并 请 求 信用 卡 授 权 。 如 果 信用 卡 有 效 ， 则 系统 创建 新 的 发 货 单 并 显示 订 
单 。 如 果 信 用 卡 无 效 ， 则 系统 显示 无 效 信用 卡 提示 。 
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Al 6-13 ”活动 图 示例 


6.14 BS 


本 章 给 出 了 需求 分 析 和 规约 的 概述 ， 并 描述 了 用 例 方法 来 定义 系统 的 功能 性 需求 。 本 章 
描述 了 参与 者 和 用 例 的 概念 ， 还 描述 了 用 例 关系 ， 特 别 是 扩展 和 包含 关系 。 

用 例 模 型 对 后 续 的 软件 开发 有 很 强 的 影响 ， 因 此 用 例 在 动态 交互 建 模 期 间 的 分 析 模 型 里 
实现 ， 如 第 9 章 和 第 11 章 所 述 。 对 于 每 个 用 例 ， 参 与 到 用 例 中 的 对 象 都 是 由 使 用 第 8 章 描 述 
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的 对 象 结 构 组 织 标准 来 确定 的 ， 并 且 定 义 了 对 象 之 间 的 交互 序列 。 软 件 能 在 项 目的 每 个 阶段 
通过 选择 要 开发 的 用 例 来 增 量 地 开发 ， 如 第 5 章 所 述 。 集 成 和 系统 测试 用 例 也 要 基于 用 例 。 
对 状态 相关 的 用 例 ， 状 态 图 也 能 用 来 描绘 状态 和 转换 ， 如 第 10 章 所 述 。 


练习 

选择 题 ( 每 道 题 选择 一 个 答案 ) 

1. 什么 是 用 例 ? 

(a) 涉及 用 户 的 案例 研究 (b) 用 户 和 系统 之 间 的 交互 序列 
(с) 用 户 和 系统 中 对 象 的 交互 序列 (а) 用 户 对 系统 的 输入 序列 
2. 用 例 中 的 参与 者 是 什么 ? 

(a) 系统 内 部 的 对 象 (b) 舞台 上 表演 的 人 

(с) 与 系统 交互 的 外 部 实体 (4) 该 系统 要 交付 给 的 那个 客户 
3. 主要 参与 者 是 什么 ? 

(а) 第 一 个 上 台 的 演员 (b ) 开始 用 例 的 参与 者 

(с) 参与 用 例 的 参与 者 (d) 系统 内 部 的 对 象 
4. 次 要 参与 者 是 什么 ? 

(а) 第 二 个 上 台 的 演员 (b) 开始 用 例 的 参与 者 

(с) 参与 用 例 的 参与 者 (а) 系统 内 部 的 对 象 
5. 用 例 中 的 可 替换 序列 是 什么 ? 

(a) 描述 错误 情况 的 序列 (b ) 与 主 序列 不 同 的 序列 

(с) 描述 与 次 要 参与 者 交互 的 序列 (d) 描述 与 主要 参与 者 交互 的 序列 
6. 包含 用 例 能 用 来 做 什么 ? 

(a) 描述 全 包含 在 内 的 用 例 (b) 描述 与 参与 者 的 长 交互 
(c) 描述 多 个 用 例 共有 的 功能 (а) 描述 包含 其 他 用 例 的 用 例 


7. 扩展 用 例 能 用 来 做 什么 ? 
(a) 描述 与 参与 者 的 长 交互 
(b ) 描述 多 个 用 例 共 有 的 功能 
(с) 描述 由 其 他 用 例 扩 展 的 用 例 的 功能 
(4) 描述 只 在 某 些 条 件 下 执行 的 不 同 用 例 的 条 件 部 分 
8. 活动 图 在 用 例 建 模 中 能 用 来 做 什么 ? 
(a) 描绘 由 系统 中 所 有 用 例 执行 的 活动 的 序列 [92 | 
(b) 描绘 与 用 例 交 互 的 外 部 活动 的 序列 
(с) 描绘 用 例 中 主动 对 象 的 序列 
(а) 描绘 用 例 的 主 序列 和 可 替换 序列 中 的 活动 
9. 非 功能 性 需求 在 用 例 模型 中 如 何 描述 ? 


(a) 在 用 例 描述 的 一 个 分 开 的 小 节 中 (b ) 作为 用 例 的 前 置 条 件 
(с) 作为 用 例 的 后 置 条 件 (4) 在 分 开 的 文档 中 
10. 什么 是 用 例 包 ? 

(a) 描述 系统 中 参与 者 的 包 (b) 描述 系统 中 用 例 的 包 


(с) 相关 用 例 的 组 (d) 参与 用 例 的 对 象 包 
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静态 模型 展示 的 是 问题 的 静态 结构 视图 ， 它 不 随时 间 的 变化 而 变化 。 一 个 静态 模型 描述 
了 被 建 模 系统 的 静态 结构 ， 相 比 系统 的 功能 ， 这 些 静 态 结构 被 认为 不 太 会 改变 。 特 别 地 ， 吏 
态 模型 定义 了 系统 中 的 类 、 这 些 类 的 属性 、 类 之 间 的 关系 以 及 每 个 类 的 操作 。 在 本 章 中 ， 静 
态 建 模 是 指 建 模 过 程 ， 采 用 UML 类 图 表示 法 来 描绘 静态 模型 。 

对 象 、 类 和 类 属性 的 概念 在 第 4 章 进 行 了 描述 ， 本 章 描 述 类 之 间 的 关系 。 有 三 种 类 型 的 
KA: 关联 ， 整 体 /部 分 ( 组合 和 聚合 ) 关系 ， 以 及 泛 化 / 特 化 (继承 ) ХХ. Hb, ЖЕ 
论述 了 问题 域 静态 建 模 的 特殊 考虑 ， 除 了 实体 类 的 静态 建 模 外 ， 还 包括 整个 系统 上 下 文 和 软 
件 系统 上 下 文 的 静态 建 模 。 类 操作 的 设计 被 延迟 到 设计 阶段 ， 在 类 设计 时 被 处 理 ( 见 第 14 25), 

静态 模型 由 类 图 描述 。7.1 节 描 述 类 之 间 不 同 种 类 的 关联 关系 。7.2 节 描 述 整体 /部 分 关 
系 ， 特 别 是 组 合 和 聚合 层次 关系 。7.3 节 描 述 泛 化 / 特 化 层次 关系 。7.4 节 概 述 约束 。7.5 节 描 
述 使 用 UML 进行 静态 建 模 ， 其 初始 重点 是 对 物理 类 和 实体 类 的 建 模 。 下 一 个 主题 包含 在 7.6 
节 中 ， 是 对 整个 系统 (硬件 和 软件 ) 的 范围 和 软件 系统 的 范围 进行 静态 建 模 ， 从 而 确定 整个 
系统 和 外 部 环境 之 间 的 边界 ， 以 及 软件 系统 和 外 部 环境 之 间 的 边界 。7.7 节 描 述 使 用 UML Ж) 
造型 对 类 进行 归 类 。7.8 节 描 述 UML 构造 型 是 如 何 应 用 于 外 部 类 的 建 模 的 。 实 体 类 ( 数据 密 

[94] ЖЖЖ) 的 静态 建 模 在 7.9 节 描 述 。 


7.1 类 之 间 的 关联 


关联 定义 了 两 个 或 多 个 类 之 间 的 关系 ， 指 明了 类 之 间 的 一 种 静态 的 、 结 构 化 的 关系 。 例 
W, “ER” (Employee) 工作 于 “部 门 ”(Department )， 这 里 “雇员 ”和 “部 门 ”是 类 ， 工 
作 于 是 一 个 关联 。 类 是 名 词 ， 而 关联 通常 是 动词 或 者 动词 短语 。 

链接 是 类 实例 ( 对象 ) 之 间 的 连接 ， 表 示 类 之 间 的 关联 的 实例 。 例 如 ，Jane 工作 于 “ 制 
造 部 门 ”( Manufacturing )， 这 里 Jane 就 是 “雇员 ”的 一 个 实例 ,“ 制 造 部 门 ” 是 “部 门 ” 的 
一 个 实例 。 两 个 对 象 之 间 可 存在 一 个 链接 ， 当 且 仅 当 它 们 相应 的 类 之 间 存 在 一 个 关联 。 

关联 本 身 是 双向 的 。 关 联 的 名 称 取 其 正 向 :“ 雇 员 ” 工 作 于 “部 门 ”。 关 联 也 有 一 个 隐 含 
的 相反 的 方向 (通常 没有 被 显 式 地 表述 ) :“ 部 门 ”雇佣 “雇员 ”。 关 联 大 部 分 是 二 元 的 一 一 即 
描述 两 个 类 之 间 的 关系 。 然 而 ,它们 也 可 以 是 一 元 的 ( 自我 关联 )、 三 元 的 或 是 多 元 的 。 


7.1.1 类 图 描述 关联 





在 类 图 中 ， 关 联 显 示 为 一 条 连接 两 个 类 框 的 弧 线 ， 弧 线 旁 边 有 关联 的 名 称 。 图 7-1 给 出 
了 关联 的 一 个 示例 :“ 公 司 ”( Company ) 被 “首席 执行 官 ”( CEO ) 领导 (Is Led by )。 
在 类 图 中 ， 关 联名 称 通常 从 左 向 右 、 自 顶 向 下 读 。 然 而 ， 在 一 个 拥有 很 多 类 的 大 规模 类 
图 里 ， 类 通常 相对 于 彼此 处 在 不 同 的 位 置 。 为 了 避免 在 读 UML 类 图 时 产生 歧义 ，COMET 使 
用 了 UML 箭头 符号 来 指明 该 从 哪个 方向 读 关 联名 称 ， 如 图 7-1 所 示 。 


ПН 5: Е 2 № 


7.1.2 关联 的 多 重 性 


关联 的 多 重 性 规定 了 一 个 类 的 多 少 个 实例 能 与 另 一 个 类 的 单个 实例 建立 关联 。 关 联 的 多 
重 性 有 以 下 几 种 情况 : 

• 一 对 一 关联 。 在 两 个 类 的 一 对 一 关联 中 ， 在 两 个 方向 上 的 关联 都 是 一 对 一 的 。 因 此 ， 
两 个 类 中 任意 一 个 类 的 一 个 对 象 只 与 另 一 个 类 的 一 个 对 象 有 一 个 链接 。 例 如 ， 在 “ 公 
司 ”被 “首席 执行 官 ”领导 这 一 关联 中 ， 一 个 特定 的 公司 仅 有 一 个 首席 执行 官 ， 而 且 
一 个 首席 执行 官 仅 是 一 个 公司 的 领导 。 一 个 例子 是 “苹果 ”( Apple ) 公司 的 首席 执行 
В + 乔布斯 。 一 对 一 关联 的 静态 建 模 表 示 法 如 图 7-1 所 示 。 

一 对 多 关联 。 在 一 对 多 关联 中 ， 两 个 类 之 间 在 一 个 方向 上 有 一 个 一 对 多 关联 ， 而 在 
相反 方向 是 一 个 一 对 一 关联 。 例 如 ， 在 “银行 ”( Bank ) 管理 (Administer) “IKA” 
( Account) 这 个 关联 中 ， 单 个 银行 管理 多 个 账户 ,但 是 一 个 账户 只 能 由 一 个 银行 管理 。 
一 对 多 关联 的 静态 建 模 表示 法 如 图 7-2 所 示 。 

规定 数值 关联 。 规 定数 值 关 联 是 一 个 指明 了 特定 数字 的 关联 。 例 如 ， 在 “汽车 ”( Car ) 
w “I” (Door) 进入 (Is entered through) 这 一 关联 中 ， 一 辆 汽车 有 两 扇 或 四 扇 门 
( 写 为 2，4 )， 但 是 绝 不 会 有 一 扇 、 三 扇 或 五 遍 门 。 相 反方 向 的 关联 依然 是 一 对 一 的 ， 
即 一 扇 车 门 只 属于 一 辆 汽车 。 注 意 ， 一 个 特定 的 汽车 制造 商 决定 一 辆 汽车 能 有 多 少 
门 ， 而 另 一 个 制造 商 可 能 做 出 不 同 的 决定 。 规 定数 值 关联 如 图 7-3 所 示 。 


тоде Мате: String 
manufacturer: String 





Company 





name: String 
employeeld: String 
address: String 
phoneNumber: Integer 


图 7-1 一 对 一 关联 的 示例 










bankName: String 
bankAddress: String 


1 






у Administers 


1:* 


accountNumber: Integer 
balance: Real 


图 7-2 一 对 多 关联 的 示例 







modelYear: Date 
1 


У 15 entered through 


图 7-3 ”规定 数值 关联 的 示例 


ө 可 选 关联 。 在 可 选 关联 中 ， 一 个 类 的 一 个 对 象 到 另 一 个 类 的 一 个 对 象 可 能 不 总 是 存在 
链接 。 例 如 ， 在 “客户 ”(Customer ) 拥有 (own) “WF” (Debit Сага) 这 一 关联 
中 ， 客 户 能 选择 是 否 拥有 一 张 借 记 卡 。 可 选 关 联 ( 零 或 一 关联 ) 如 图 7-4 所 示 。 也 可 
以 有 零 或 一 或 多 关联 。 例 如 ， 在 “客户 ”拥有 “信用 卡 ”( Credit Сага) 这 一 关联 中 ， 
一 个 客户 可 以 没有 信用 卡 、 有 一 张 信 用 卡 或 者 多 张 信 用 卡 ， 如 图 7-5 所 示 。 注 意 ， 在 
这 两 个 例子 中 ， 相 反方 向 的 关联 都 是 一 对 一 的 (例如 ,“ 借 记 卡 ”被 “客户 ”拥有 )。 


多 对 多 关联 。 多 对 多 关联 是 在 两 个 类 之 间 的 两 个 方向 上 各 是 一 个 一 对 多 关联 的 关联 。 
例如 ， 在 “课程 ”( Course ) W “Æ” (Student) #45 (Is attended by ) “学 生 ” 参 


ae (Enroll in) “课程 ”这 一 关联 中 ,在 课程 和 听课 学 生 之 间 有 一 个 一 对 多 关联 ， 因 为 
一 个 课程 有 多 个 学 生 听 课 。 在 相反 方向 也 有 一 个 一 对 多 关联 ， 因 为 一 个 学 生 可 以 参加 


70 #205 Kt BH 





多 个 课程 。 这 种 情况 如 图 7-6 所 示 ， 关 联 在 两 个 方向 上 都 被 显示 出 来 。 


customerName: String 
customerld: String 
customerAddress: String 


сага1д: Integer 

PIN: String 
startDate: Date 
expirationDate: Date 
status: Integer 

limit: Real 

total: Real 


图 7-4 可 选 ( 零 或 一 ) 关联 





customerName: String 
customerld: String 
customerAddress: String 





courseld: String 
courseName: String 


section#: Integer 
semester: String 






Enrolls in А | У Isattended by 


cardType: Integer 
cardId: Integer 
startDate: Date 
expirationDate: Date 
status: Integer 


studentName: String 
studentld: String 
studentAddress: String 
studentType: String 


# 7-5 п] (297—802) 关联 图 7-6 多 对 多 关联 


图 7-7 给 出 了 在 银行 应 用 中 各 个 类 和 它们 之 间 关 联 的 一 个 例子 。 “银行 ”类 分 别 与 “ 客 
户 ” 类 和 “ 借 记 卡 ”类 都 有 一 个 一 对 多 关联 。 因 此 ， 一 个 银行 为 多 个 客户 提供 服务 以 及 管理 
多 张 借 记 卡 。“ 客 户 ” 与 “账户 ”有 一 个 多 对 多 关联 ， 所 以 一 个 客户 可 拥有 不 止 一 个 账户 ， 一 
个 账户 也 可 以 是 多 个 客户 的 共同 账户 。“ 客 户 ” 与 “ 借 记 卡 ” 有 一 个 可 选 关联 ， 所 以 一 个 给 定 
的 客户 可 以 拥有 一 张 也 可 以 没有 借 记 卡 ,但 是 一 张 借 记 卡 必须 属于 一 个 客户 。“ 银 行 ” 和 “总 
裁 ”( President ) 有 一 个 一 对 一 关联 ， 所 以 银行 只 能 有 一 个 总 裁 ， 一 个 总 裁 仅 能 作为 一 个 银行 
的 总 裁 。 这 些 类 的 属性 如 图 7-8 所 示 。 


Managed by 

















accountNumber : Integer 
balance : Real 








- 
DebitCard 


cardId : String 
PIN : String 
startDate : Date 
expirationDate : Date 
status : Integer 

limit : Real 

total : Real 


name : String 









Provides access to 
> 









DebitCard 


customerName : String 
customerld ; String 
customerAddress : String 






employeeld ; String 
address : String 
phoneNumber : Integer 





图 7-8 类 属性 的 示例 
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7.1.3 三 元 关联 


三 元 关联 是 在 类 之 间 的 三 个 方向 的 关联 。 三 元 关联 的 一 个 例子 是 “买方 ”( Buyer )、“ 卖 
27" (Seller) 和 “中 介 ”( Agent ) 三 个 类 之 间 的 关联 。 该 关联 是 “买方 ”通过 “中 介 ” 和 
“卖方 ”协商 价格 。 如 图 7-9 所 示 。 三 元 关联 展示 为 一 个 连接 三 个 类 的 萎 形 。 更 高 阶 的 关联 ， 





即 三 个 类 以 上 的 关联 是 十 分 罕见 的 。 







name: String 

address: String 
phoneNumber: Integer 
movingDateTarget: String 
homePriceTarget: Integer 












name: String 
address: String 

phoneNumber: Integer 
sellingPrice: Integer 





name: String 
address: String 

company: String 
workPhoneNumber: String 
homePhoneNumber: String 


图 7-9 三 元 关联 示例 


7.1.4 一 元 关联 


一 元 关联 (也 称 为 自身 关联 ) 是 一 个 类 的 一 个 对 象 与 同一 个 类 的 另 一 个 对 象 之 间 的 关联 。 


例如 “人 ”(Person ) 是 “人 ”( Person ) 的 孩子 (Is child of ) (图 7-10 ), 


Is child of 
“人 ”与 “人 ”结婚 (15 married to), “雇员 ” 是 “雇员 ”的 老板 s | | Ы 


boss of )。 


715 关联 类 Person 


关联 类 是 对 两 个 或 多 个 类 之 间 的 关联 进行 建 模 的 类 。 关 联 类 的 


属性 就 是 该 关联 的 属性 。 在 两 个 或 多 个 类 之 间 的 复杂 关联 中 ， 关 联 ATO 一 天 关联 不 例 
是 有 可 能 拥有 属性 的 。 这 经 常 发 生 在 多 对 多 关联 中 ， 其 中 属性 不 属于 任何 一 个 类 ， 而 是 属 


于 该 关联 。 


看 一 个 关联 类 的 例子 ， 考 虑 “项 目 ”( Project ) 类 和 “雇员 ”( Employee ) 类 之 间 的 多 对 
多 关联 。 在 该 关联 中 ， 一 个 项 目 配备 了 多 个 雇员 ， 一 个 雇员 可 以 工作 于 多 个 项 目 : 


“ME” feg (Is staffed by) “SER” 
“雇员 ”工作 于 ( Works on) “HA” 


7-11 说 明了 这 两 个 类 ( “雇员 ”类 和 “项 目 ” 类 ) 以 及 一 个 称 为 “小 时 数 ”( Honurs ) 
的 关联 类 ， 其 属性 是 “工作 小 时 数 ”( hoursWorked )。 这 个 “工作 小 时 数 ” 属 性 既 不 是 “ 雇 
员 ” 类 的 属性 也 不 是 “项 目 ” 类 的 属性 ， 它 是 “雇员 ”类 和 “项 目 ” 类 之 间 关 联 的 一 个 属性 ， 
因为 它 表 示 一 个 特定 的 雇员 ( 多 个 雇员 当中 特定 的 一 个 ) 在 一 个 特定 的 项 目 (一 个 雇员 工作 


于 多 个 项 目 ) 上 的 工作 时 间 。 
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Employee 


employeeName: String 
employeeld: String 
employeeAddress: String 
level: String 


















ртојес а: String 
ртојес Мате: String 
startDate: Date 
endDate: Date 
customer: String 











14 Is staffed by 
| 


hoursWorked: Real 


图 7-11 关联 类 示例 






72 ”组合 和 聚合 层次 


组 合 和 聚合 层次 都 是 讨论 一 个 类 由 其 他 类 构成 的 情况 。 组 合 和 聚合 都 是 关系 的 特殊 形 
A: 类 通过 整体 / 部 分 关系 连接 起 来 。 在 这 两 种 情况 下 ， 部 分 和 整体 间 的 关系 是 一 个 15 part of 
(是 … 的 一 部 分 ) ЖЖ. 

组 合 是 一 种 比 聚 合 更 强 的 关系 ， 聚 合 是 一 种 比 关 联 更 强 的 关系 。 特 别 地 ， 组 合 关系 是 一 
种 在 部 分 和 整体 之 间 比 聚合 关系 更 强 的 关系 。 组 合 也 是 实例 之 间 的 关系 。 因 此 ， 部 分 对 象 的 
创建 、 存 在 和 消亡 都 是 和 整体 一 起 的 。 部 分 对 象 只 能 属于 一 个 整体 。 

组 合 类 经 常 涉及 整体 和 部 分 之 间 的 物理 关系 。 因 此 ，ATM 机 是 一 个 由 四 个 部 分 组 成 的 组 
ВУ; “TER AE” (CardReader ),“ 吐 钞 器 ”( Cash Dispenser )， 赁 条 打印 机 ( Receipt Printer ) 
以 及 “ATM 客户 键盘 显示 器 ”( АТМ Customer Keypad Display ) Ж ( 如 图 7-12 所 示 ). АТМ 
组 合 类 和 它 的 四 个 部 分 类 中 的 每 一 个 都 有 一 个 一 对 一 关联 。 






1 1 1 1 
ATMCustomer z г г 
sae 

图 7-12 组 合 层次 示例 


聚合 层次 是 整体 / 部 分 关系 的 一 种 较 弱 的 形式 。 在 一 个 聚合 里 ， 部 分 实例 能 添加 到 聚合 
整体 中 ， 也 能 从 聚合 整体 中 移 除 。 由 于 这 个 原因 ， 聚 合 有 可 能 被 用 来 对 概念 类 建 模 ， 而 不 是 
对 物理 类 建 模 。 此 外 ， 一 个 部 分 可 以 属于 多 个 聚合 。 聚 合 层次 的 一 个 例子 是 大 学 里 的 “学 院 ” 
(College ) (图 7-13 )， 其 部 分 是 “管理 办 公 室 ”( Admin Office )、 一 些 “ 系 ”( Department ) 以 
及 一 些 “ 研 究 中 心 ”( Research Center )。 可 以 创建 新 的 系 ， 时 常 也 可 以 撤销 老 的 系 或 者 与 其 他 
系 合并 。 可 以 创建 研究 中 心 ， 或 者 撤销 、 合 并 研究 中 心 。 


collegeName: String 
dean: String 













1 
Admin Office 


location: String deptName: String name: String 
phone#: String deptLocation: String location: String 
administrator: String i 






foundingDate: Date 
renewalDate: Date 


图 7-13 聚合 层次 示例 
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在 组 合 和 聚合 里 ， 属 性 都 从 整体 向 部 分 传播 。 因 此 ， 每 个 ATM 机 的 唯一 标识 ATM Id 也 


标识 了 特定 的 读 卡 器 、 吐 钞 器 和 客户 键盘 / 显示器， 作为 ATM 组 合 类 的 部 分 。 
7.3 泛 化 / 特 化 层次 


有 一 些 类 相似 但 不 相同 ， 它 们 有 些 共同 的 属性 ， 也 有 其 他 不 同 的 属性 。 在 泛 化 / 特 化 层 
次 中 ， 共 同属 性 被 抽象 到 一 个 泛 化 类 ， 称 作 超 类 。 不 同 的 属性 是 特 化 类 的 性 质 ， 特 化 类 被 称 
作 子 类 。 在 子 类 和 超 类 之 间 有 一 个 Is a 的 关系 。 超 类 也 被 称 为 父 类 或 祖先 类 。 子 类 也 被 称 为 
孩子 类 或 者 子孙 类 。 

每 一 个 子 类 继承 了 超 类 的 性 质 ， 但 是 也 对 这 些 性 质 以 不 同 的 方式 进行 了 扩展 。 一 个 
类 的 性 质 是 其 属性 或 操作 。 继 承 允 


许 对 父 类 进行 适 配 ， 来 形成 子 类 。 
accountNumber: Integer 
А 









子 类 从 超 类 继承 了 属性 和 操作 。 子 
类 还 可 以 增加 属性 、 增 加 操作 或 者 
重 定义 操作 。 每 一 个 子 类 自身 也 可 
以 成 为 超 类 ， 进 一 步 特 化 形成 其 他 
子 类 。 设 计 超 类 和 子 类 的 操作 将 在 
第 14 章 描 述 。 

考虑 图 7-14 给 出 的 银行 账户 的 例 
子 。 活 期 账户 (Checking Account) 和 
EIK (Savings Account ) “有 一 些 共同 的 属性 ， 而 其 他 属性 则 是 不 同 的 。 所 有 账户 的 共同 属 
性 一 一 即 “ 账 号 ”( accountNumber ) 和 “余额 ”( balance ) 一 一 作为 超 类 “账户 ”( Account ) 
的 属性 。 储 蓄 账 户 特 有 的 属性 ， 例 如 产生 的 “利息 ”( interest ) ( 在 这 个 银行 中 ， 活 期 账户 不 
产生 任何 利息 )， 作 为 子 类 “储蓄 账户 ”的 属性 。 活 期 账户 特有 的 属性 ， 例 如 “最 后 存款 金 


#1 ” (lastDepositAmount )， 作 为 子 类 
т 
balance: Real 


“储蓄 账户 ”Is a“ 账 户 ”。 
“活期 账户 ”Is a“ 账 户 "。 





lastDepositAmount: Real 


SavingsAccount 


interest: Real 





Е 7-14 泛 化 / 特 化 层次 












区 分 器 是 表明 对 象 的 哪个 性 质 被 = 
泛 化 关系 用 来 进行 抽象 的 一 种 属性 。 
例如 ， 上 述 “ 账 户 ” 泛 化 中 的 区 分 器 
“账户 类 型 ”( accountType ) 区 分 了 “ 活 
期 账户 ”和 “储蓄 账户 "， 如 图 7-15 所 ES Ane шунан 


示 。 区 分 器 并 不 需要 成 为 泛 化 类 或 特 化 类 的 一 个 属性 。 因 此 ， 它 不 是 “账户 ” 超 类 或 其 两 个 
子 类 的 属性 。 


7.4 ”约束 


约束 规定 了 必须 为 真 的 条 件 或 限制 (Rumbaugh, Booch, and Jacobson 2005 )。 约 束 可 使 
用 任何 文本 语言 表示 。UML 也 提供 了 一 种 约束 语言 对 象 约束 语言 (OCL, Warmer and 
Kleppe 1999 )， 可 选择 性 地 加 以 使 用 。 





© Checking Account 多 用 于 美国 英语 ， 表 示 活 期 账户 ; Savings Account 多 用 于 英国 英语 ， 表 示 储 蓄 账 户 。 这 
里 举 这 个 例子 并非 中 文字 面 意思 上 活期 账户 是 储蓄 账户 的 一 种 。 一 一 译 者 注 
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有 一 种 约束 是 对 属性 的 可 能 值 的 限制 。 考 虑 下 面 的 例子 : 在 银行 的 例子 中 ， 可 能 规定 账 
户 不 允许 有 负 余 额 。 这 可 以 表示 为 一 个 在 “账户 ”类 的 “余额 ”属性 上 的 约束 ， 来 说 明 余 领 


不 允许 为 负 值 : {“ 余 额 ”>=0}。 在 类 图 里 ， 属 性 上 的 约束 写 
在 相应 的 属性 旁边 ， 如 图 7-16 所 示 。 

另 一 种 约束 是 在 关联 链接 上 的 限制 。 通 常 ， 一 个 关联 中 
“多 ”端的 对 象 是 没有 顺序 的 。 然 而 ， 在 某 些 情况 下 ， 问 题 
域 中 的 对 象 可 能 有 一 个 希望 被 建 模 的 显 式 的 顺序 。 例 如 ， 考 
虑 一 对 多 关联 :“ 账 户 ” 被 “ATM 交易 ”修改 。 在 这 个 关联 
里 ，ATM 交易 是 根据 时 间 排 序 的 ; 因此 ， 约 束 可 以 表示 为 
{ 根据 时 间 排 序 }。 这 种 约束 可 以 在 类 图 中 描述 ， 如 图 7-17 
所 示 。 


accountNumber: Integer 
balance: Real {balance >= 0} 


图 7-16 ”对象 约 束 示例 


accountNumber; Integer 
balance: Real 


1 
















У Modified by 


* {ordered by time} 


ATMTransaction 


transactionId: Integer 


7.5 静态 建 模 和 UML 


COMET 中 所 采用 的 方法 是 早 在 分 析 阶 段 就 有 一 个 概念 静 
态 模型 ， 用 来 对 问题 域 建 模 并 有 助 于 对 问题 域 的 理解 。 其 目标 
是 专注 于 问题 域 中 能 从 静态 建 模 得 到 最 大 收益 的 那些 部 分 ， 万 
其 是 物理 类 和 数据 密集 型 类 ( 被 称 为 实体 类 )。 本 节 描 述 了 在 
分 析 期 间 实 施 的 初始 概念 静态 建 模 ; 在 设计 阶段 实施 的 更 详细 图 7-17 关联 中 排序 约束 示例 
的 静态 建 模 在 第 14 章 描 述 。 


status: Integer 


问题 域 的 静态 建 模 


在 问题 域 的 静态 建 模 中 ， 最 初 的 重点 是 对 物理 类 和 实体 类 建 模 。 物 理 类 是 有 物理 特性 的 
类 一 一 即 它们 能 被 看 到 和 摸 到 。 这 样 的 类 包括 物理 设备 ( 能 入 式 应 用 中 ,， 这 往往 是 问题 域 的 
一 部 分 )、 用户 、 外 部 系统 和 计时 器 。 实 体 类 是 概念 上 的 数据 密集 型 类 ， 通 常 是 持久 的 一 一 即 
长 久 存 在 。 实 体 类 在 信息 系统 中 尤其 普遍 ( 例如 在 银行 应 用 中 的 账户 和 交易 )。 

在 有 多 个 物理 设备 ( 如 传感器 和 执行 器 ) 的 谋 入 式 系统 中 ， 类 图 能 有 助 于 对 这 些 真 实 世 
界 的 设备 建 模 。 例 如 ， 在 银行 系统 中 ，ATM 机 是 一 个 戏 人 的 子 系统 ,那么 它 对 于 真实 世界 的 
设备 、 设 备 的 关联 以 及 关联 的 多 重 性 进行 建 模 是 有 很 用 的 。 组 合 类 常常 被 用 来 展示 真实 世界 
的 类 是 怎样 和 其 他 类 组 合 的 ( 例如 ， 图 7-18 所 描绘 的 ATM 机 )。 

考虑 银行 应 用 问题 域 的 静态 模型 。 银 行为 多 个 ATM 机 提供 了 一 个 服务 ， 如 图 7-18 所 示 。 
每 一 个 ATM 机 是 由 一 个 “ 读 卡 器 ”( Сага Reader )、 一 个 “ 吐 钞 器 ”( Cash Dispenser )、 一 
个 “和 赁 条 打印 机 ”( Receipt Printer) 和 一 个 “ATM 客户 键盘 显示 器 ”( ATM Customer Keypad 
Display ) 组 成 的 组 合 类 。 “АТМ 客户 ”参与 者 将 卡 插 人 “ 读 卡 器 "， 并 通过 “ATM 键盘 显示 
器 ”进行 交互 。“ 吐 钞 器 ”将 现金 发 放 给 “ATM 客户 ”参与 者 。“ 和 赁 条 打印 机 ”为 “ATM 客 
户 ” 参 与 者 打印 一 张 收据 。 这 些 物 理 实体 代表 了 问题 域 中 的 类 ， 对 这 些 类 需要 在 软件 系统 中 
有 一 种 概念 表示 。 在 对 象 和 类 的 构造 期 间 需 要 做 出 这 些 决 策 ( 如 第 8 章 所 述 )。 另 外 ,“ 操 作 
员 ”( Operator ) 参与 者 是 一 个 用 户 ， 他 的 工作 是 维护 ATM 机 。 
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1 
ATMCustomer 
KeypadDisplay 
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Interacts through 


ATM Customer 


B 7-18 “银行 系统 ”的 概念 静态 建 模 


76 ”系统 上 下 文 的 静态 建 模 


理解 一 个 计算 机 系统 的 范围 是 非常 重要 的 ， 特 别 是 什么 要 包含 在 系统 之 内 ， 什 么 要 留 在 
系统 之 外 。 上 下 文 建 模 显 式 地 标识 了 什么 是 在 系统 内 的 ， 什 么 是 在 系统 外 的 。 上 下 文 建 模 可 
以 在 整个 系统 ( 硬件 和 软件 ) 的 级 别 上 完成 ， 或 者 在 软件 系统 ( 仅 软件 ) 的 级 别 上 完成 。 显 
式 地 展现 了 作为 黑 盒 对 待 的 系统 ( 硬件 和 软件 ) 和 外 部 环境 间 边 界 的 图 称 为 系统 上 下 文 图 。 
显 式 地 展现 了 软件 系统 ( 也 作为 黑 盒 对 待 ) 和 外 部 环境 ( 包含 硬件 ) 间 边界 的 图 称 为 软件 系 
统 上 下 文 图 。 这 些 系统 边界 的 视图 比 通常 由 用 例 图 给 出 的 边界 要 更 详细 。 

在 开发 系统 上 下 文 图 的 过 程 中 ， 在 考虑 软件 系统 的 上 下 文 之 前 考虑 整个 硬件 /软件 系统 
( 即 硬件 和 软件 两 方面 ) 的 上 下 文 是 有 帮助 的 ， 这 在 需要 对 硬件 /软件 做 出 权衡 的 情况 下 特别 
有 用 。 在 考虑 整个 硬件 /软件 系统 时 ， 只 有 用 户 〈 即 人 类 参与 者 ) 和 外 部 系统 在 系统 之 外 。 
输入 /输出 (IO ) 设备 是 系统 硬件 的 一 部 分 ， 因 此 会 出 现在 整个 系统 的 内 部 。 

考虑 “银行 系统 ”的 整个 硬件 /软件 系统 作为 例子 。 从 整个 硬件 /软件 系统 的 视角 来 看 ， 
“АТМ 客户 ”和 “ATM 操作 员 ” 参 与 者 ( 图 7-18 ) 在 系统 外 ， 如 图 7-19 所 示 。 图 7-18 中 所 
示 的 所 有 其 他 实体 ， 特 别 是 输入 /输出 设备 (包括 读 卡 器 、 吐 钞 器 、 任 条 打印 机 和 ATM 客户 
键盘 / 显示 器 )， 是 整个 硬件 /软件 系统 的 一 
部 分 (图 7-19 )。 

从 整个 系统 的 视角 即 硬件 和 软件 两 方面 г 
KE, “АТМ 客户 ”和 “ATM 操作 员 ” 参 与 
者 是 在 系统 的 外 部 ， 如 图 7-19 所 示 。“ATM самы 
操作 员 ” 通 过 键盘 和 显示 器 与 系统 交互 。 рро 银行 硬件 /软件 系统 的 上 下 文 类 图 
“АТМ 客户 ”参与 者 通过 四 个 输入 /输出 设备 
( 读 卡 器 、 吐 钞 器 、 赁 条 打印 机 和 АТМ 客户 键盘 /显示 器 ) 与 系统 交互 。 从 整个 硬件 /软件 






Intcracts 
ыз with ® 






«system» 





System 
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系统 的 视角 来 看 ， 这 些 输入 /输出 设备 是 系统 的 一 部 分 。 从 软件 的 视角 来 看 ， 这 些 输入 /输出 
设备 是 在 软件 系统 的 外 部 。 在 软件 系统 上 下 文 类 图 中 ， 这 些 输入 /输出 设备 被 建 模 为 外 部 类 ， 
如 图 7-20 所 示 。 





ATM 
Customer 


图 7-20 银行 系统 的 上 下 文 类 图 


软件 系统 上 下 文 类 图 能 够 通过 对 连接 到 该 系统 的 外 部 类 进行 静态 建 模 来 确定 。 特 别 地 ， 
上 一 节 所 描述 的 物理 类 通常 是 输入 /输出 设备 ， 它 们 是 软件 系统 的 外 部 类 。 另 外 ， 软 件 系统 
上 下 文 类 图 也 能 通过 在 用 例 中 考虑 参与 者 及 其 使 用 什么 设备 接 人 系统 来 确定 。 这 两 种 方法 都 
在 7.8 节 描 述 。 


77 使 用 UML 构造 型 对 类 分 类 


字典 里 分 类 的 定义 是 “在 归 类 系统 中 一 种 特别 定义 的 划分 ”。 在 类 构造 中 ，COMET 方法 
主张 对 类 进行 分 类 ， 从 而 将 具有 相似 特性 的 类 分 组 到 一 起 。 由 于 基于 继承 的 归 类 是 面向 对 象 
建 模 的 一 个 目标 ， 因 此 采用 继承 本 质 上 就 是 一 种 自然 的 归 类 策略 。 这 样 ， 把 账户 类 分 为 活期 
账户 和 储蓄 账户 是 个 好 主意 ， 这 是 因为 活期 账户 和 储蓄 账户 有 些 共同 的 属性 和 操作 ， 也 有 其 
他 不 同 之 处 。 然 而 ,分 类 是 一 种 战略 上 的 归 类 一 一 一 种 决策 将 类 组 织 成 某 些 组 ， 因 为 大 部 分 
软件 系统 拥有 这 些 种 类 的 类 ， 而 且 通 过 这 种 方法 对 类 分 类 有 助 于 更 好 地 理解 被 开发 的 系统 。 
在 UML 里 ,构造 型 被 用 来 区 别 不 同 种 类 的 类 。 构 造型 是 现 有 建 模 元 素 ( 如 一 个 应 用 程序 
或 外 部 类 ) 的 子 类 ， 用 来 代表 一 种 用 法 区 别 ( 如 应 用 的 种 类 或 外 部 类 的 种 类 )。 在 UML 标记 
法 中 ， 构 造型 由 一 对 双 尖 括号 (类似 于 汉语 书 名 号 ) 括 起 来 ， 例 如 《实体 》(entity )。 在 软件 
应 用 中 ， 类 根据 它 在 应 用 中 扮演 的 角色 进行 分 类 ， 例 如 «实体 »》(entity ) 类 或 者 «边界 » 
(boundary) 类 ， 这 些 将 在 第 8 章 中 


中 的 特 ， 点 进 行 分 类 的 А 例 如 & 外 部 系 CardReader ReceiptPrinter Account 


i » (external system) 或 者 «外 部 用 


+r KE «external output device» «entity» 
论述 。 


图 7-21 展示 的 例子 是 “银行 系统 ” 图 7-21 UML 类 及 其 构造 型 示例 
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的 外 部 输入 /输出 设备 “ 读 卡 器 ”( Card Reader )， 外 部 输出 设备 “ 吐 钞 器 ”( Cash Dispenser ) 
和 “ 赁 条 打印 机 ”( Receipt Printer )， 以 及 实体 类 “账户 ”( Account ) 和 “客户 ”( Customer )。 


7.8 外 部 类 建 模 


静态 建 模 使 用 UML 表示 法 ， 系 统 上 下 文 将 硬件 /软件 系统 显示 为 一 个 有 构造 型 < 系统 > 
(system) 的 聚合 类 ， 外 部 环境 描绘 成 外 部 类 ， 系 统 必须 对 该 类 有 接口 ， 如 图 7-19 所 示 。 在 软 
件 系统 的 情况 下 ， 上 下 文 将 软件 系统 显示 为 一 个 有 构造 型 « 软件 系统 》( «software system» ) 
的 聚合 类 ， 外 部 环境 描绘 成 外 部 类 ， 软 件 系 统 必须 对 该 类 有 接口 ， 如 图 7-20 所 示 。 

图 7-22 展示 了 外 部 类 通过 构造 型 ( 见 7.7 节 ) 进行 分 类 的 情况 ; 这 样 ， 构 造型 就 用 来 
区 分 各 种 各 样 的 外 部 类 。 图 7-22 中 ， 每 个 方 框 代表 了 外 部 类 的 一 种 不 同 的 分 类 ， 它 们 之 间 
的 关系 是 继承 关系 。 这 样 ， 一 个 外 部 类 就 被 分 类 为 «外 部 用 户 »》 类 、« 外 部 设备 ”( external 
device ) 类 、« 外 部 系统 (external system) 类 或 者 « 外 部 计时 器 »、( external timer) №. Я 
有 外 部 用 户 和 外 部 系统 才 是 整个 系统 的 真正 外 部 。 人 硬件 设备 和 计时 器 是 整个 系统 的 一 部 分 ， 
但 是 对 于 软件 系统 是 外 部 。 这 样 ， 图 7-22 便 从 软件 系统 的 视角 将 外 部 类 进行 分 类 。 


«external class» 
A 


«extemal 
re 
device» 
А 
«external input «external output «external input / 
device» device» output device» 


Е 7-22 通过 构造 型 对 外 部 类 分 类 


如 图 7-22 所 示 ， 外 部 设备 被 进一步 分 类 如 下 : 

• 外 部 输入 设备 。 仅 向 系统 提供 输入 的 设备 ， 例 如 传感器 。 

e 外 部 输出 设备 。 仅 从 系统 接收 输出 的 设备 ， 例 如 执行 器 。 

e 外 部 输入 / 输出 设备 。 向 系统 提供 输入 并 从 系统 接收 输出 的 设备 ， 例 如 ATM 读 卡 器 。 

人 类 用 户 经 常 通过 标准 的 输入 /输出 设备 〈 例如 键盘 、 显 示 器 和 鼠标 ) 和 软件 系统 进行 交 
互 。 我 们 对 这 些 标准 输入 /输出 设备 的 特性 并 不 感 兴趣 ， 因 为 它们 由 操作 系统 处 理 。 就 向 用 户 
输出 哪些 信息 和 由 用 户 输入 哪些 信息 而 言 ， 我 们 对 用 户 的 接口 要 感 兴趣 得 多 。 为 此 ， 通 过 标 
准 输入 /输出 设备 和 软件 系统 交互 的 外 部 用 户 被 描述 为 一 个 « 外 部 用 户 » (external user )。 

一 个 通用 的 指南 是 ， 一 方面 ， 只 有 在 用 户 通 过 标准 输入 /输出 设备 和 系统 交互 时 ， 人 类 
用 户 才 要 表示 为 一 个 外 部 用 户 类 。 另 一 方面 ， 如 果 用 户 通 过 特定 于 应 用 的 输入 /输出 设备 和 
软件 系统 进行 交互 ， 那 么 这 些 输入 /输出 设备 就 要 表示 为 外 部 输入 /输出 设备 类 。 

对 于 一 个 实时 骨 和 人 式 系 统 ， 和 希望 标识 出 低层 次 的 外 部 类 ， 这 些 外 部 类 对 应 于 软件 系统 
必须 有 接口 连接 的 物理 输入 /输出 设备 。 这 些 外 部 类 使 用 构造 型 < 外 部 输入 /输出 设备 > 
(external ИО device) 描述 。 例 如 ， 在 “自动 引导 车 辆 系统 ”中 ,“ 到 达 传 感 器 ”( Arrival 
Sensor ) 外 部 输入 设备 和 “发 动机 ”( Motor ) 外 部 输出 设备 。 

当 系 统 接口 到 其 他 系统 时 ， 就 需要 一 个 «外 部 系统 »》 类 ,或 者 发 送 数 据 ， 或 者 接收 数 
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据 。 这 样 ， 在 “自动 引导 车 辆 系统 ”中 ， 软 件 系 统 有 接口 连接 到 两 个 外 部 系统 :“ 监 管 系统 ” 
(Supervisory System ) 和 “显示 系统 ”( Display System )。 

如 果 一 个 应 用 需要 追踪 时 间 ， 并 且 /或 者 如 果 它 需要 外 部 计时 器 事 件 来 启动 系统 中 的 某 些 动 
作 ， 那 么 就 要 使 用 « 外 部 计时 器 类。 在 实时 系统 中 ， 外 部 计时 器 类 是 最 频繁 被 用 到 的 。“ 自 动 
引导 车 辆 系统 ”中 的 一 个 例子 是 “时 钟 ”( Clock )。 因 为 软件 系统 需要 外 部 计时 器 事件 来 启动 各 
种 周期 性 的 活动 ， 所 以 需要 这 样 一 个 时 钟 。 有 时 ， 对 周期 性 活动 的 需要 要 在 设计 阶段 才 会 明显 。 

软件 系统 聚合 类 和 外 部 类 之 间 的 关联 描述 是 在 软件 系统 上 下 文 类 图 中 ， 特 别 显示 出 关联 
的 多 重 性 。 软 件 系统 上 下 文 类 图 中 标准 的 关联 名 称 是 : 输入 到 ， 输 出 到 ， 和 … 通 信 ， 和 … 交 
互 ， 向 … 发 信号 。 这 些 关联 按 如 下 方式 使 用 : 


«外 部 输入 设备 » (external input device) 输入 到 «软件 系统 » 
(软件 系统 》 输 出 到 《 外 部 输出 设备 » (external output device ) 
«外 部 用 户 »》 和 «软件 系统 » 交 互 


«外 部 系统 »》 和 «软件 系统 »》 通 信 
« 外 部 计时 器 》 向 《软件 系统 》 发 信号 





软件 系统 上 下 文 类 图 中 关联 的 示例 如 下 : 


读 卡 器 输入 到 “银行 系统 ” 
“银行 系统 ”输出 到 吐 钞 器 
操作 员 和 “银行 系统 ”交互 


“监管 系统 ”和 “自动 引导 车 辆 系统 ”通信 
时 钟 向 “自动 引导 车 辆 系统 ”发 信号 





7.8.1 从 外 部 类 开发 软件 系统 上 下 文 类 图 示例 


从 外 部 类 开发 软件 系统 上 下 文 类 图 的 示例 如 图 7-20 所 示 ， 图 中 显示 了 和 “银行 系统 ” 必 
须 接口 的 外 部 类 。 这 些 外 部 类 是 从 前 述 问题 域 的 静态 模型 中 直接 确定 的 。 而 且 ， 这 些 外 部 类 
都 通过 构造 型 分 类 。 

在 这 个 例子 中 ， 三 个 输入 /输出 设备 被 分 类 为 外 部 设备 类 :“ 读 卡 器 "“ 和 赁 条 打印 机 ”和 
“ 吐 钞 器 " 。 因 为 外 部 类 “ATM 客户 键盘 / 显示 器 ”是 标准 输入 /输出 设备 ， 因 此 被 分 类 为 外 
部 用 户 类 。 同 样 的 原因 ， 操 作 员 外 部 类 也 被 分 类 为 外 部 用 户 类 。 因 为 对 每 个 АТМ 机 ， 这 些 外 
部 类 都 有 一 个 实例 ,并且 存 在 多 个 ATM 机 ， 所 以 每 个 外 部 类 和 “银行 系统 ”之 间 都 有 一 个 
一 对 多 关联 。 图 7-23 展示 了 用 构造 型 描述 的 外 部 类 的 软件 系统 上 下 文 类 图 。 在 软件 系统 上 下 
文 类 图 中 显 式 地 标明 了 外 部 类 构造 型 ， 直 观 地 描述 了 系统 中 每 个 外 部 类 所 扮演 的 角色 。 这 样 ， 
哪个 类 表示 外 部 输出 设备 ， 哪 个 类 表示 外 部 用 户 ， 就 显而易见 了 。 

软件 系统 上 下 文 类 图 的 另 一 个 示例 是 “自动 引导 车 辆 系统 ”， 如 图 7-24 所 示 。 这 个 软件 
系统 有 六 个 外 部 类 :两 个 外 部 系统 (“监管 系统 ”和 “显示 系统 ”), 一 个 外 部 输入 设备 (“到 
达 传 感 器 ”)， 两 个 外 部 输出 设备 ( ”机械 臂 ”和 “发 动机 ”)， 以 及 一 个 外 部 计时 器 (“时钟 ”)。 


7.8.2 ”参与 者 和 外 部 类 
下 一 步 考 虑 如 何 通过 分 析 和 系统 交互 的 参与 者 来 导出 软件 系统 上 下 文 类 图 。 参 与 者 是 一 
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图 7-24 带 有 外 部 类 构造 型 的 “自动 引导 车 辆 系统 ”软件 系统 上 下 文 类 图 


个 比 外 部 类 更 抽象 的 概念 。 参 与 者 和 外 部 类 之 间 的 关系 如 下 : 

。 输入 /输出 设备 参与 者 等 同 于 外 部 输入 /输出 设备 类 。 这 意味 着 输入 /输出 设备 参与 者 
通过 外 部 输入 /输出 设备 类 连接 到 系统 。 

© 外 部 系统 参与 者 等 同 于 外 部 系统 类 。 

© 计时 器 参与 者 通过 外 部 计时 器 类 连接 到 系统 ， 外 部 计时 器 类 向 系统 提供 计时 器 事件 。 

© 人 类 用 户 参与 者 有 最 大 的 灵活 性 。 在 最 简单 的 情况 下 ， 用 户 参 与 者 通过 标准 用 户 输 
入 /输出 设备 (例如 键盘 、 显 示 器 和 鼠标 ) 连接 到 系统 。 外 部 类 被 给 予 其 用 户 参 与 者 
的 名 称 ， 因 为 感 兴趣 的 是 来 自用 户 的 逻辑 信息 。 然 而 ， 在 更 复杂 的 用 例 下 ， 人 类 参与 
者 有 可 能 通过 多 种 外 部 类 连接 到 系统 。 "银行 系统 ”中 客户 参与 者 就 是 这 样 一 个 例子 ， 
参与 者 通过 多 个 外 部 输入 /输出 设备 与 系统 连接 ， 如 7.8.3 节 所 述 。 


783 ”从 参与 者 开发 软件 系统 上 下 文 类 图 示例 


为 了 从 参与 者 确定 外 部 类 ， 有 必要 理解 每 个 参与 者 的 特性 以 及 每 个 参与 者 是 如 何 与 系统 交 
互 的 (如 用 例 中 所 述 )。 考 虑 所 有 参与 者 都 是 人 类 用 户 的 情况 。 在 “银行 系统 ”中 ， 有 两 个 参与 
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者 ， 它 们 都 是 人 类 用 户 :“ATM 客户 ”和 “ATM 操作 员 ”， 如 图 7-19 的 系统 上 下 文 类 图 所 示 。 

图 7-23 显示 了 “银行 系统 ”的 软件 系统 上 下 文 类 图 ， 其 中 “银行 系统 ”作为 一 个 聚合 
类 ， 外 部 类 连接 到 “银行 系统 "。“ATM 操作 员 ” 参 与 者 通过 一 个 标准 用 户 输入 /输出 设备 连 
接 到 系统 ， 并 被 描述 为 一 个 称 为 “操作 员 ” 的 « 外 部 用 户 类， 因为 在 这 个 情况 下 ， 用 户 的 
特性 比 输入 /输出 设备 的 特性 更 重要 。 然 而 ,客户 参与 者 实际 上 是 通过 一 个 代表 了 键盘 / 显示 
器 和 三 个 特定 应 用 的 输入 /输出 设备 的 标准 用 户 输入 / 输出 设备 连接 到 系统 的 。 这 三 个 特定 应 
用 的 输入 /输出 设备 是 : 一 个 < 外 部 输入 /输出 设备 > “BER AR”, РА < 外 部 输出 设备 > “GE 
条 打印 机 ”和 “ 吐 钞 器 "。 这 五 个 外 部 类 和 “银行 系统 ”都 有 一 对 多 关联 。 


79 实体 类 的 静态 建 模 


实体 类 是 概念 性 的 数据 密集 型 类 一 一 它们 的 主要 目的 是 存储 数据 并 提供 对 这 些 数 据 的 访 
问 。 在 许多 情况 下 ， 实 体 类 是 持久 的 ， 这 意味 着 数据 是 长 久 存在 的 ， 并 需要 存储 于 文件 或 数 
据 库 中 。 尽 管 一 些 方法 主张 在 分 析 阶 段 对 所 有 的 软件 类 进行 静态 建 模 ，COMET 方法 还 是 强 
调 了 实体 类 的 静态 建 模 ， 从 而 能 充分 利用 静态 建 模 表示 法 在 表达 类 、 属 性 和 类 之 间 的 关系 方 
面 的 优势 。 实 体 类 在 信息 系统 中 非常 普遍 ; 然而 ， 很 多 实时 和 分 布 式 系统 有 可 观 的 数据 密集 
型 类 。 关 注 于 实体 类 建 模 类 似 于 对 逻辑 数据 库 模 式 的 建 模 。 实 体 类 通常 在 设计 阶段 映射 到 一 
个 数据 库 ， 如 第 15 章 所 述 。 

面向 对 象 的 静态 建 模 和 频繁 用 于 逻辑 数据 库 设 计 的 实体 关系 建 模 的 主要 不 同 是 ， 尽 管 两 
种 方法 都 对 类 、 类 属性 、 类 间 关 系 建 模 ， 但 面向 对 象 的 静态 建 模 还 允许 规定 类 的 操作 。 在 问 
题 域 的 静态 建 模 期 间 ，COMET 的 重点 是 确定 在 问题 中 定义 的 实体 类 、 它 们 的 属性 和 它们 的 关 
系 。 规 定 操作 被 延迟 到 设计 建 模 时 (如 第 14 章 所 述 )。 实 体 类 的 静态 建 模 被 称 为 实体 类 建 模 。 

实体 类 建 模 的 一 个 示例 来 自 于 一 个 在 线 购 物 应 用 ， 其 中 客户 、 账 户 和 商品 目录 都 在 问题 
描述 中 提 到 了 。 这 些 现 实 世 界 概念 实体 的 每 一 个 都 被 建 模 为 一 个 实体 类 ， 并 使 用 构造 型 « 实 
体 ”描述 。 每 个 实体 类 的 属性 都 被 确定 ， 并 且 定 义 了 实体 类 之 间 的 关系 。 

在 线 购物 应 用 的 实体 类 模型 的 示例 如 图 7-25 所 示 。 因 为 这 个 静态 模型 描述 的 仅 为 实体 类 ， 
所 以 所 有 的 类 都 有 “实体 > 构造 型 来 描述 它们 在 应 用 中 所 扮演 的 角色 。 图 7-25 显示 了 “客户 ” 
(Customer ) 实体 类 ， 它 和 “客户 账户 ”( Customer Account ) 类 有 一 个 一 对 一 关联 ， 后 者 又 和 
“REAL” (Delivery Order) 类 有 一 个 一 对 多 的 关联 关系 。“ 发 货 单 ”类 是 “商品 ”( Item ) 类 的 
聚合 ， 而 “商品 ”类 又 和 “商品 目录 ”( Catalog ) Ж ( 其 中 描述 商品 ) 有 一 个 多 对 一 关联 ， 和 
“EFP” (Inventory ) ( 其 中 存储 商品 ) 有 一 个 可 选 关联 (其 中 的 0 是 因为 特定 的 商品 可 能 在 库 
存 中 缺 货 )。 这 个 例子 在 “在 线 购物 系统 ”案例 研究 中 有 更 详细 的 描述 ( 见 第 22 章 )。 


类 属性 建 模 


在 对 实体 类 的 建 模 中 ， 一 个 重要 的 考虑 是 定义 每 个 实体 类 的 属性 。 实 体 类 是 数据 密集 型 
的 ， 这 意味 着 它 有 多 个 属性 。 如 果 一 个 实体 类 看 上 去 只 有 一 个 属性 ， 那么 它 是 否 真 的 是 一 个 
实体 类 就 有 问题 了 。 事 实 上 ， 这 个 有 疑问 的 实体 更 有 可 能 应 该 建 模 为 另外 一 个 类 的 属性 。 

考虑 图 7-26 所 示 实 体 类 的 属性 。 每 个 类 有 多 个 属性 ， 提 供 了 该 类 区 别 于 其 他 类 的 信息 。 
此 外 ， 类 的 每 个 实例 有 这 些 属性 的 特定 值 去 区 分 该 类 的 其 他 实例 。 这 样 ， 客 户 类 通过 属性 体现 
了 其 特性 ， 这 些 属性 描述 了 需要 识别 单个 客户 的 信息 ， 包 括 客户 一 、 客 户 姓名 、 地 址 、 电 话 
号 码 、 传 真 号 码 和 电子 邮件 地 址 。 另 一 方面 ， 客 户 账户 类 包含 了 提供 账户 的 详细 信息 的 属性 。 
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图 7-25 在 线 购物 应 用 的 实体 类 模型 


«entity» «entity» «entity» 
DeliveryOrder Customer Item 
orderld : Integer customerid ; Integer 
orderStatus ; OrderstatusType customerName : String 
accountid : Integer address : String 


amountDue: Real telephoneNumber : String 
supplierld : Integer faxNumber : String 
creationDate : Date email : EmailType 
plannedShipDate : Date 
actualShipDate : Date 
paymentDate: Date 


itemid : Integer 
unitCost : Real 
quantity : Integer 


i «entity» 
«entity» жепшу» beast 
Inventory Catalog 


| supplierld : Integer 
itemID : Integer itemld : Integer у supplierName: String 
itemDescription : String itemDescription : String address : String 

quantity : Integer unitCost : Real telephoneNumber : String 
price : Real supplierid ; Integer faxNumber : String 


reorderTime : Date itemDetails : linkType email : EmailType 


«entity» 
CustomerAccount 


accountld : Integer 
cardld ; String 
cardType : String 
expirationDate: Date 


图 7-26 在 线 购物 应 用 程序 的 实体 类 属性 





тло 总 结 


本 章 描述 了 静态 建 模 的 一 些 基 本 概念 ， 包 括 了 类 之 间 的 关系 。 本 章 描述 了 三 种 类 型 的 关 
Ж: 关联 、 组 合 /聚合 关系 和 泛 化 / 特 化 关系 。 男 外 ， 本 章 描述 了 静态 建 模 是 如 何 被 使 用 来 对 
问题 域 的 结构 视图 进行 建 模 。 其 中 包含 了 : 整个 系统 上 下 文 的 静态 建 模 ， 它 描述 了 在 整个 硬 
件 /软件 系统 之 外 的 类 ; 软件 系统 上 下 文 的 静态 建 模 ， 它 描述 了 在 软件 系统 之 外 的 类 ; 实体 
类 (概念 性 的 数据 密集 型 类 ) 的 静态 建 模 。 

解决 方案 域 的 静态 建 模 被 延迟 到 设计 阶段 。 尽 管 静态 建 模 也 包括 定义 每 个 类 的 操作 ， 但 
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在 动态 建 模 后 确定 一 个 类 的 操作 会 更 加 容易 。 因 此 ， 确 定 一 个 类 的 操作 被 延迟 到 类 设计 阶段 ， 
如 第 14 章 所 述 。 


练习 
选择 题 ( 每 道 题 选 择 一 个 答案 ) 
1. 什么 是 类 ? 
(а) 课程 (b) 对 象 实例 
(с) 系统 中 的 客户 端 或 服务 器 (d) 具有 相同 特性 的 对 象 的 集合 
2. 什么 是 属性 ? 
(a) 两 个 类 之 间 的 关系 (b) 操作 或 方法 的 参数 
(с) 类 的 对 象 所 持 有 的 一 个 数据 值 (а) 操作 的 返回 值 
3. 什么 是 关联 ? 
(a ) 两 个 类 之 间 的 关系 (b) 两 个 对 象 之 间 的 关系 
(с) 两 个 类 之 间 的 链接 (а) 两 个 对 象 之 间 的 链接 


4. 关联 关系 的 多 重 性 指 的 是 什么 ? 
(a) 一 个 类 中 关联 的 数量 
(b) 两 个 类 之 间 关 联 的 数量 
(с) 一 个 类 有 多 少 个 实例 和 另 一 个 类 的 多 少 个 实例 相关 
(а) 一 个 类 有 多 少 个 实例 和 另 一 个 类 的 单个 实例 相关 
5. 什么 是 关联 类 ? 
(a) 有 多 个 关联 的 类 
(b) 有 一 个 关联 的 类 
(с) 对 两 个 或 多 个 类 之 间 的 关联 建 模 的 类 
( 4) 对 两 个 或 多 个 对 象 之 间 的 关联 建 模 的 类 
6. 什么 是 泛 化 / 特 化 层次 ? 
(a) 整体 /部 分 关系 (b) 继承 关系 
(с) 泛 化 类 和 特 化 类 之 间 的 关联 (d) 分 层 的 层次 结构 
7. 什么 是 组 合 层次 ? 
(a) 泛 化 / 特 化 层次 的 弱化 形式 (b) 泛 化 / 特 化 层次 的 强化 形式 
(с) 整体 / 部 分 关系 的 弱化 形式 (4) 整体 /部 分 关系 的 强化 形式 
8. 什么 是 聚合 层次 ? 
(a) 泛 化 / 特 化 层次 的 弱化 形式 (b) 泛 化 / 特 化 层次 的 强化 形式 
(с) 整体 /部 分 关系 的 弱化 形式 (4) 整体 /部 分 关系 的 强化 形式 
9. 系统 上 下 文 类 图 定义 了 什么 ? 
(a) 系统 中 的 实体 类 (b) 系统 怎样 连接 到 其 他 系统 
(с) 系统 和 外 部 环境 之 间 的 边界 (d) 系统 中 的 上 下 文 类 
10. 什么 是 实体 类 ? 
(a) 实体 /关系 图 中 的 类 (b ) 存储 数据 的 类 
114 (с) 连接 到 外 部 实体 的 类 (d) 外 部 类 
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对 象 和 类 组 织 


在 定义 了 用 例 和 开发 了 问题 域 的 静态 模型 后 ， 下 一 步 是 确定 系统 的 软件 对 象 。 在 这 个 阶 
段 ， 重 点 在 对 问题 域 中 真实 世界 对 象 进 行 建 模 的 软件 对 象 上 。 

软件 对 象 是 由 用 例 和 问题 域 的 静态 模型 确定 的 。 本 章 为 如 何 确定 系统 中 的 对 象 提供 了 指 
南 ， 给 出 了 对 象 构造 的 标准 ， 并 通过 使 用 构造 型 对 对 象 进行 分 类 。 重 点 是 在 真实 世界 中 发 现 
的 问题 域 对 象 ， 而 不 是 在 设计 时 确定 的 解 域 对 象 。 

在 第 7 章 中 描述 的 静态 建 模 被 用 来 确定 外 部 类 ， 然 后 这 些 外 部 类 会 被 描绘 在 软件 系统 上 
下 文 类 图 中 。 这 些 外 部 类 用 来 帮助 确定 软件 边界 类 一 一 连接 到 外 部 环境 并 与 之 通信 的 软件 类 。 
实体 类 及 其 关系 也 是 在 静态 建 模 时 确定 的 。 本 章 中 ， 软 件 系统 所 需要 的 对 象 和 类 被 确定 和 分 
类 。 特 别 地 ， 本 章 的 焦点 是 那些 在 问题 域 静态 建 模 期 间 没有 被 确定 的 附加 的 软件 对 象 和 类 。 

类 之 间 的 静态 关系 是 在 静态 模型 中 考虑 的 ( 如 前 一 章 所 述 )， 而 对 象 之 间 的 动态 关系 是 在 
动态 模型 中 考虑 的 ， 这 将 在 第 9、10、11 章 论述 。 

8.1 节 给 出 了 对 象 和 类 的 构造 的 概述 。8.2 节 描 述 了 对 应 用 类 和 对 象 进行 建 模 。8.3 节 给 出 
了 对 象 和 类 构造 分 类 的 概述 。8.4 节 描 述 了 外 部 类 ( 在 第 7 章 中 首次 介绍 ) 及 其 与 软件 边界 类 
的 关系 。8.5 节 描 述 了 不 同 种 类 的 边界 类 和 对 象 。8.6 节 描 述 了 实体 类 和 对 象 ， 这些 在 第 7 章 
中 首次 介绍 。8.7 节 描 述 了 不 同 种 类 的 控制 类 和 对 象 。8.8 节 描 述 了 应 用 逻辑 的 类 和 对 象 。 


8.1 对象 和 类 的 组 织 准 则 


没有 一 个 统一 的 方式 将 一 个 系统 分 解 为 对 象 ， 因 为 做 出 这 些 决 策 都 是 基于 分 析 员 的 判断 
和 问题 的 特性 。 对 象 是 否 是 同一 个 类 或 是 不 同 的 类 依赖 于 问题 的 本 质 。 例 如 ， 在 汽车 目录 中 ， 
轿车 、 面 包车 、 卡 车 可 能 是 同一 个 类 的 对 象 。 然 而 ， 对 于 汽车 制造 商 而 言 ， 轿 车 、 面 包车 、 
卡车 可 能 是 不 同类 的 对 象 。 这 种 现象 的 原因 可 能 是 ， 对 于 汽车 目录 而 言 ， 每 种 汽车 需要 相同 
类 型 的 信息 ; 而 对 于 汽车 制造 商 而 言 ， 则 需要 更 详细 的 信息 ， 对 不 同类 型 的 车 是 不 相同 的 。 

本 章 给 出 了 对 象 和 类 构造 标准 来 辅助 设计 者 将 一 个 系统 构建 成 对 象 。 用 来 标识 对 象 的 方 
法 是 在 问题 域 中 寻找 真实 世界 对 象 ， 然 后 设计 相对 应 的 软件 对 象 对 真实 世界 建 模 。 在 标识 出 
这 些 对 象 之 后 ， 对 象 之 间 的 交互 就 在 动态 模型 的 通信 图 或 顺序 图 中 描述 出 来 ( 见 第 9、11 章 )。 


8.2 ”对 应 用 类 和 对 和 象 建 模 


7.9 节 描 述 了 实体 类 的 静态 建 模 ， 这 主要 从 分 析 阶 段 的 静态 建 模 中 收益 ， 因 为 实体 类 是 
信息 密集 的 。 然 而 ， 实 体 类 只 是 系统 中 软件 类 的 一 种 。 在 着 手动 态 建 模 ( 见 第 9、10、11 章 ) 
之 前 ， 有 必要 确定 需要 哪些 软件 类 和 对 象 来 实现 每 一 个 用 例 。 标 识 软件 对 象 和 类 能 通过 应 用 
对 象 和 类 的 构造 标准 来 得 到 很 大 的 辅助 ， 这 些 标准 为 将 一 个 应 用 构建 成 对 象 提 供 了 指导 。 这 
种 方法 通过 它们 在 应 用 中 所 扮演 的 角色 来 对 软件 类 和 对 象 进行 分 类 。 

在 这 一 步 中 ， 类 被 分 类 ， 使 得 带 有 相似 特性 的 类 被 分 组 到 一 起 。 图 8-1 展示 了 应 用 类 的 
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[16] 分 类 。 构 造型 ( 见 7.7 节 ) 被 用 来 区 分 不 同 种 类 的 应 用 类 。 因 为 对 象 是 类 的 实例 ， 所 以 对 象 
拥有 和 它 所 实例 化 的 类 相同 的 构造 型 。 因 此 ， 在 本 节 中 所 描述 的 分 类 对 类 和 对 象 是 一 样 的 。 


«application class» 
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Е 8-1 用 构造 型 对 应 用 类 分 类 


在 图 8-1 中 ， 每 一 个 框 代 表 应 用 类 的 不 同 分 类 ， 它 们 之 间 的 关系 是 继承 关系 。 因 此 ， 应 用 类 
被 分 类 为 实体 类 、 边 界 类 、 控 制 类 或 应 用 逻辑 类 。 这 些 构 造型 又 被 进一步 分 类 ， 如 图 8-1 所 示 。 

这 个 分 类 过 程 类 似 于 图 书馆 中 对 书籍 的 分 类 ， 有 主要 的 类 别 (如 小 说 和 非 小 说 )， 以 及 进 
一 步 将 小 说 分 类 为 经 典 、 神 秘 、 冒 险 等 ， 将 非 小 说 分 类 为 传记 、 自 传 、 旅 游 、 亮 饪 、 历 史 以 
及 其 他 分 类 。 这 个 过 程 也 类 似 于 对 动物 王国 的 分 类 ， 可 划分 为 主要 的 类 别 〈 哺乳 动物 、 鸟 类 、 
鱼 类 、 疏 行动 物 等 )， 并 进一步 划分 成 子 类 别 【 如 猫 、 狗 、 猴 子 都 是 哺乳 动物 的 子 类 别 )。 


83 对象 和 类 的 组 织 分 类 


对 象 和 类 是 根据 它们 在 应 用 中 所 扮演 的 角色 来 分 类 的 。 有 四 个 主要 的 对 象 和 类 的 构造 分 
类 ， 如 图 8-1 所 示 : 边界 对 象 、 实 体 对 象 、 控 制 对 象 以 及 应 用 逻辑 对 象 。 大 多 数 应 用 会 拥有 
这 四 个 类 别 中 每 个 类 别 的 对 象 。 然 而 ， 不 同类 型 的 应 用 会 在 某 个 分 类 中 拥有 大 量 的 类 。 因 此 ， 
信息 密集 型 系统 将 有 多 个 实体 类 ， 这 就 是 为 什么 静态 建 模 对 这 些 系统 如 此 重要 。 另 一 方面 ， 
实时 系统 更 有 可 能 拥有 多 个 设备 输入 /输出 边界 类 来 连接 各 种 传感器 和 执行 器 。 它 们 还 可 能 
拥有 复杂 的 状态 相关 的 控制 类 ， 因 为 这 些 系统 是 与 状态 高 度 相关 的 。 这 些 对 象 构造 分 类 总 结 
在 下 面 的 列表 中 ， 并 在 8.4 到 8.7 节 中 详 述 。 

四 个 主要 的 对 象 和 类 构造 分 类 如 下 : 

1) 实体 对 象 。 一 种 软件 对 象 ， 很 多 情况 下 是 持久 的 ， 封 装 了 信息 并 提供 对 它 所 储存 信息 
的 访问 。 在 某 些 情 况 下 ， 实 体 对 象 可 以 通过 服务 对 象 访问 。 

2) 边界 对 象 。 连 接 到 外 部 环境 并 与 之 通信 的 软件 对 象 。 边 界 对 象 进一步 分 类 如 下 : 

• 用 户 交 互 对 象 。 与 人 类 用 户 进行 交互 并 通过 接口 连接 到 人 类 用 户 的 软件 对 象 。 

• 代理 对 象 。 连 接 到 外 部 系统 或 者 子 系统 并 与 之 通信 的 软件 对 象 。 

© 设备 UO 边界 对 象 。 从 硬件 输入 /输出 设备 接收 输入 或 向 硬件 输入 /输出 (1O ) 设备 

输出 的 软件 对 象 。 

3) 控制 对 象 。 对 对 象 的 集合 提供 全 局 协调 的 软件 对 象 。 控 制 对 象 可 以 是 协调 者 对 象 、 状 

17] ” 态 相 关 控 制 对 象 或 计时 器 对 象 。 
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4) 应 用 逻辑 对 象 。 包 含 应 用 逻辑 细节 的 软件 对 象 。 当 希望 从 正在 操纵 的 数据 中 分 开 隐藏 
应 用 逻辑 时 需要 这 种 软件 对 象 ， 因 为 我 们 认为 有 可 能 应 用 逮 辑 会 独立 于 数据 发 生变 化 。 对 信 
息 系统 而 言 ， 应 用 逻辑 对 象 通常 是 业务 逻辑 对 象 ， 而 对 实时 应 用 、 科 学 应 用 或 工程 应 用 而 言 ， 
应 用 逻辑 对 象 通常 是 算法 对 象 。 另 一 个 分 类 是 服务 对 象 ， 为 客户 对 象 提 供 服务 ， 典 型 地 存在 
于 面向 服务 的 架构 和 应 用 中 。 

在 大 部 分 情况 下 ， 一 个 对 象 属 于 哪个 分 类 通常 是 显而易见 的 。 然 而 ， 在 某 些 情况 下 ， 一 
个 对 象 有 可 能 满足 上 面 标准 中 的 多 个 。 例 如 ， 一 个 对 象 可 以 同时 具备 实体 对 象 ( 封装 了 某 些 
数据 ) 和 算法 对 象 (执行 了 一 个 重要 的 算法 ) 的 特性 。 在 这 些 情况 下 ， 可 将 该 对 象 分 配给 看 
上 去 更 适合 的 分 类 。 注 意 ， 更 重要 的 是 要 确定 系统 中 的 所 有 对 象 ， 而 不 是 过 分 关心 如 何 分 类 
少量 模棱两可 的 情况 。 

对 每 一 个 对 象 结构 组 织 准 则 ， 有 一 个 对 象 行为 模式 ， 它 描述 了 该 对 象 如 何 与 其 相 邻 对 象 进 
行 交 互 。 理 解 对 象 的 典型 行为 模式 是 很 有 用 处 的 ， 因 为 当 在 一 个 应 用 中 使 用 这 种 对 象 分 类 时 ， 往 
往 会 以 相似 的 方式 与 相同 种 类 的 相 邻 对 象 进行 交互 。 每 一 种 行为 模式 都 在 UML 通信 图 中 描述 。 


8.4 外 部 类 与 软件 边界 类 


正如 7.8 节 所 述 ， 外 部 类 是 那些 在 软件 系统 外 部 并 且 通 过 接口 连接 到 系统 的 类 。 边 界 类 
是 系统 内 部 的 类 ， 通 过 接口 连接 到 外 部 类 并 与 其 通信 。 为 了 帮助 确定 系统 中 的 边界 类 ， 有 必 
要 考虑 和 它们 相连 的 外 部 类 。 

标识 出 那些 与 系统 通信 并 通过 接口 连接 到 系统 的 外 部 类 对 标识 系统 自身 的 一 些 类 ( 即 边 
界 类 ) 是 有 帮助 的 。 每 一 个 外 部 类 与 一 个 系统 中 的 边界 类 进行 通信 。 通 常 在 外 部 类 ( 假定 它 
已 经 被 正确 地 标识 出 来 ) 和 与 之 通信 的 内 部 边界 类 之 间 存 在 一 对 一 的 关联 。 外 部 类 用 以 下 方 
式 通过 接口 连接 到 软件 边界 类 : 
外 部 用 户 类 通过 接口 连接 到 用 户 交 互 类 ， 并 与 之 交互 。 
外 部 系统 类 通过 接口 连接 到 代理 类 ， 并 与 之 通信 和 。 
e 外 部 设备 类 为 设备 VO 边界 类 提供 输入 和 / 或 接收 其 输出 。 继 续 分 类 为 : 
© 外 部 输入 设备 类 向 输入 类 提供 输入 。 
。 外 部 输出 设备 类 接收 来 自 输出 类 的 输出 。 
© 外 部 O 设备 类 向 VO 类 提供 输入 并 接收 其 输出 。 
外 部 计时 器 类 向 软件 计时 器 类 发 信号 。 

一 个 外 部 设备 类 代表 一 个 IO 设备 类 型 。 一 个 外 部 VO 设备 对 象 代表 一 个 特定 的 IO 设 
备 ， 即 该 设备 类 型 的 一 个 实例 。 在 下 一 节 中 , 我们 考虑 通过 接口 连接 到 外 部 对 象 并 与 之 通信 
的 内 部 对 象 。 


8.5 边界 类 和 对 象 


本 节 描 述 了 三 种 不 同 种 类 的 边界 对 象 的 特性 。 这 三 种 边界 对 象 是 : 用 户 交 互 对 象 、 代 理 
对 象 和 设备 IO 边界 对 象 。 在 每 种 情况 下 ， 都 将 给 出 边界 类 的 一 个 示例 ， 后 面 跟 该 边界 类 的 
实例 ( 即 边界 对 象 ) 采用 典型 的 交互 序列 与 相 邻 对 象 通信 的 行为 模式 的 示例 。 


8.5.1 用 户 交 互 对 象 


用 户 交 互 对 象 直接 与 人 类 用 户 通信 ， 从 用 户 获 取 输 入 ， 通 过 标准 IO 设备 〈 如 键盘 、 显 
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示 器 和 鼠标 ) 向 用 户 提供 输出 。 依 赖 于 用 户 接口 技术 ， 用 户 接口 可 能 非常 简单 〈 比如 命令 行 
接口 )， 也 有 可 能 更 复杂 ( 比如 图 形 化 用 户 界面 [GUI] 对 象 )。 用户 交 互 对 象 可 以 是 一 个 组 合 
对 象 ， 由 几 个 较 简 单 的 用 户 交 互 对 象 组 成 。 这 意味 着 用 户 通过 多 个 用 户 交 互 对 象 与 系统 交互 。 


这 些 对 象 用 “ 用户 交 互 » (user interaction ) 构造 型 描述 。 


图 8-2a 中 描述 了 一 个 简单 的 用 户 交 互 类 一 一 “操作 员 交 互 ”( Operator Interaction ) 一 一 的 
示例 。 该 类 的 一 个 实例 是 “操作 员 交 互 ”对 象 ( 见 图 8-2b )， 该 对 象 用 用 户 交 互 对 象 的 典型 行 
为 模式 来 描述 。 这 个 对 象 接受 来 自 于 操作 员 参 与 者 的 操作 员 命 令 ; 从 一 个 实体 对 象 “ 传 感 器 
数据 资源 库 ”( Sensor Data Repository ) 请 求 传感器 数据 ; 并 把 接收 到 的 数据 显示 给 操作 员 。 
也 可 能 有 更 复杂 的 用 户 交 互 对 象 ， 例 如 ,“ 操 作 员 交互 ”对 象 可 以 是 由 几 个 较 简单 的 用 户 交 互 
对 象 组 合 而 成 的 组 合用 户 交 互 对 象 。 这 就 允许 操作 员 在 一 个 窗口 中 接收 工作 站 状态 的 动态 更 
新 ， 在 另 一 个 窗口 中 接收 警报 状态 的 动态 更 新 ， 在 第 三 个 窗口 中 与 系统 进行 交互 式 对 话 。 每 
一 个 窗口 都 是 由 多 个 GUI 部 件 组 成 ， 比 如 菜单 、 按 钮 和 更 简单 的 窗口 。 


«user interaction» 


Operator 


Interaction 


a) 


8.5.2 RENZ 


代理 对 象 通过 接口 连接 到 外 部 系统 并 与 之 通信 。 代 理 对 象 是 外 部 系统 的 本 地 代表 ， 隐 藏 
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b) 
图 8-2 用 户 交 互 类 和 对 象 示 例 


了 了 “如何” 与 外 部 系统 通信 的 细节 。 


代理 类 的 一 个 例子 是 “ 抓 取 和 放置 机 器 人 代理 ”( Pick & Place Robot Proxy) 类 。 图 8-3 
给 出 了 代理 对 象 的 行为 模式 的 示例 ， 其 中 描述 了 通过 接口 连接 到 “外 部 抓 取 和 放置 机 器 人 ” 
( External Pick & Place Robot ) 并 与 之 通信 的 “ 抓 取 和 放置 机 器 人 代理 ”对 象 。“ 抓 取 和 放置 机 
器 人 代理 ”对 象 对 “外 部 抓 取 和 放置 机 器 人 ”发 出 “ 抓 取 ”( pick ) 和 “放置 ”( place ) 机 器 


人 命令 。 真 实 世 界 的 机 器 人 对 命令 进行 响应 。 


«proxy» 
Pick&Place 
Robot 
Proxy 


a) 











«proxy» 


: Pick&Place 
Robot < 一 
Proxy 2: Pick & Place 


Robot Response 
软件 对 象 


系统 边界 
b) 
图 8-3 ”代理 类 和 对 象 示例 


注 : 系统 边界 虚线 仅 供 说 明 用 途 ， 并 不 符合 ОМІ 表示 法 。 


每 一 个 代理 对 象 都 隐藏 了 如 何 通过 接口 与 特定 外 部 系统 连接 并 与 之 通信 的 细节 。 代 理 
对 象 更 有 可 能 通过 向 外 部 的 计算 机 控制 的 系统 发 送 消息 的 方式 进行 通信 ( 如 前 述 机 器 人 的 例 


Request 







3: Sensor Data 


1 
! 1: Pick & Place 
Robot Command 








«entity» 
: SensorData 
Repository 













«external 
system» 
; External 
Pick&Place 

Robot 
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子 )， 而 不 是 像 设 备 VO 边界 对 象 那样 通过 传感器 和 执行 回来 通信 。 然 而 ， 这 些 问 题 都 要 到 设 
计 阶 段 才 会 处 理 。 


8.5.3 设备 /О 边界 对 象 


设备 по 边界 对 象 对 一 个 硬件 VO 设备 提供 软件 接口 。 设 备 VO 边界 对 象 对 非 标准 的 特 
定 应 用 IO 设备 是 必需 的 ,这些 非 标准 设备 在 实时 系统 中 更 加 普遍 ， 尽 管 它们 在 其 他 系统 中 
也 经 常用 到 。 标 准 IO 设备 典型 地 由 操作 系统 来 处 理 ， 因 而 专用 设备 ИО 边界 对 象 不 需要 作为 
应 用 的 一 部 分 来 开发 。 

在 应 用 领域 中 的 物理 对 象 是 拥有 一 些 物理 特性 ( 如 它 能 被 看 见 和 摸 到 ) 的 真实 世界 对 象 。 
对 于 每 一 个 与 问题 相关 的 真实 世界 对 象 ， 在 系统 中 都 要 有 与 之 相对 应 的 软件 对 象 。 例 如 ， 在 “ 自 
动 引导 车 辆 系统 ”中 ， 发 动机 和 机 械 辟 与 真实 世界 的 物理 对 象 是 相关 的 ， 因 为 它们 与 软件 系统 交 
互 。 另 一 方面 ， 车 辆 底盘 和 车 轮 与 真实 世界 对 象 是 不 相关 的 ， 因 为 它们 不 与 软件 系统 交互 。 在 软 
件 系 统 中 ， 相 关 的 真实 世界 物理 对 象 通过 软件 对 象 来 建 模 ， 比 如 车 辆 发 动机 和 机 械 臂 软件 对 象 。 

真实 世界 物理 对 象 通常 通过 传 感 顺 和 执行 锅 连 接 到 系统 。 这 些 真 实 世 界 对 象 通过 传 感 需 
向 系统 提供 输入 ， 通 过 执行 器 接收 来 自 系 统 的 输出 。 因 此 ， 对 于 软件 系统 ， 真 实 世 界 对 象 实 
际 上 是 向 系统 提供 输入 和 接收 系统 输出 的 IO 设备 。 因 为 真实 世界 对 象 对 应 于 ИО 设备 ， 所 以 
连接 到 它们 的 软件 对 象 被 称 为 设备 VO 边界 对 象 。 

例如 ， 在 “自动 引导 车 辆 系统 ”中 ， 车 站 到 达 指 示 需 是 一 个 真实 世界 对 象 ， 它 拥有 一 个 
传感器 (输入 设备 ) 用 来 向 系统 提供 输入 。 发 动机 和 机 械 臂 是 真实 世界 对 象 ， 由 执行 器 (їй 
出 设备 ) 控制 ， 接 收 系统 的 输出 。 

输入 对 象 是 一 种 设备 VO 边界 对 象 ， 从 一 个 外 部 输入 设备 获取 输入 。 图 8-4 给 出 了 一 个 输 
人 类 的 例子 : 在 通信 图 中 ， 一 个 输入 类 “温度 传感器 接口 ”( Temperature Sensor Interface ) 和 
一 个 这 个 类 的 实例 ( 一 个 输入 对 象 )。 输 入 对 象 aTemperatureSensorInterface 从 外 部 真实 世界 硬 
件 对 象 aReal-World TemperatureSensor 输入 设备 接收 温度 传感器 输入 。 图 8-4 在 显示 硬件 构造 
型 « 外 部 输入 设备 ”( external input device ) 和 软件 输入 » (input ) 对 象 的 同时 ， 也 显示 了 硬 
件 /软件 边界 。 这 样 ， 输 入 对 象 就 向 外 部 硬件 输入 设备 提供 了 软件 系统 接口 。 










1 
| 
1: Temperature | 
1 
1 





















«input» кү input Sensor Input «input» 
Temperature Ce == aTemperature 
Sensor oo Sensor 
Interface Spee Interface 

Sensor 
is X 
真实 世界 硬件 对 象 软件 对 象 
1 
硬件 /软件 边界 
a) b) 


图 8-4 输入 类 与 对 象 示例 
ж: 系统 边界 虚线 仅 供 说 明 用 途 ， 并 不 符合 UML 表示 法 。 


输出 对 象 是 一 个 设备 1/O 边界 对 和 象 ， 向 外 部 输出 设备 发 送 输出 。 图 8-5 给 出 了 输出 类 的 
一 个 例子 : 一 个 叫做 “ 红 灯 接 口 ”( Red Light Interface) 的 输出 类 ， 连 同 该 类 的 一 个 实例 Red 
Light Interface 对 象 ， 它 向 外 部 真实 世界 对 象 “ 红 灯 执 行 器 ”(Red Light Actuator ) 输出 设备 发 
送 输出 。Red Light Interface 软件 对 象 向 硬件 Red Light Actuator 发 出 “ 开 ” 或 “ 关 ” 的 灯光 命 
令 (Light command )。 图 8-5 同样 显示 了 软件 / 便 件 边界 。 
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1; Light Command 










1 
1 
| 
1 
1 
1 
1 
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воћу «external output 
«output» йр <— device» 






RedLight : RedLight ‘device 
Interface Interface | : керы 
软件 对 象 ! ”真实 世界 硬件 对 象 
О 
硬件 /软件 边界 
a) b) 


图 8-5 输出 类 和 对 象 示例 
Ж: 系统 边界 虚线 仅 供 说 明 用 途 ， 并 不 符合 ОМІ 表示 法 。 


硬件 VO 设备 也 可 以 是 一 种 既 向 系统 提供 输入 、 又 能 从 系统 接收 输出 的 设备 ， 其 相应 的 
软件 类 是 IO 类 ， 从 这 个 类 实例 化 出 来 的 软件 对 象 是 一 个 IO 对 象 。 输 入 /输出 (VO) 对 象 
是 一 种 设备 VO 边界 对 象 ， 从 外 部 IO 设备 接收 输入 ， 并 向 外 部 IO 设备 发 送 输出 。 这 种 情况 


， 就 是 “ATM 读 卡 器 接口 ”( АТМ Card Reader Interface ) Ж ( 见 图 8-6a ) 及 其 实例 “ATM ЕЕ 


器 接口 ”对 象 ( 见 图 8-6b )， 该 对 象 从 外 部 UO“ 设 备 АТМ 读 卡 器 ”( АТМ Card Reader ) 接 
We ATM 卡 输入 。 另 外 ，ATM Card Reader Interface 还 向 读 卡 器 发 送 弹 卡 和 吞 卡 输出 命令 。 


t 
1 
1 
1: Card Reader 
«extemal input/ Input 


1 
1 
| 
«input/output» Е | «input/outpub» 
ATMCardReader аи — : ATMCardReader 
Interface | = | Interface 
Reader 2: Card Reader 1 
Output 1 
真实 世界 硬件 对 象 і 软件 对 象 
1 
硬件 /软件 边界 
a) b) 


图 8-6 VO 类 和 对 象 示例 
+. 系统 边界 虚线 仅 供 说 明 用 途 ， 并 不 符合 UML 表示 法 。 


在 一 些 应 用 中 ， 有 许多 相同 类 型 的 真实 世界 对 象 。 对 每 一 个 真实 世界 对 象 都 由 一 个 设 
备 VO 对 象 的 方式 来 建 模 ， 所 有 这 些 对 象 都 是 同一 个 类 的 实例 。 例 如 ， 工 厂 自动 化 系统 控制 
了 许多 自动 引导 的 车 辆 ， 拥 有 许多 相同 类 型 的 车 辆 发 动机 和 相同 类 型 的 机 械 臂 。 对 每 一 个 自 
动 引导 的 车 辆 ， 都 有 “发 动机 接口 ”( Motor Interface) 类 的 一 个 实例 和 “机 械 臂 接口 ”( Arm 
Interface ) 类 的 一 个 实例 。 


8.5.4 描述 外 部 类 和 边界 类 


第 7 章 讨 论 了 如 何 确 定 系统 范围 以 及 如 何 画 出 软件 系统 上 下 文 类 图 ， 以 展示 所 有 通过 接口 
连接 到 系统 并 与 之 通信 的 外 部 类 。 扩 展 该 图 来 展示 与 外 部 类 通信 的 边界 类 是 很 有 用 的 。 边 界 类 是 
系统 内 部 的 软件 类 ， 它 们 处 于 系统 和 外 部 环境 间 的 边界 上 。 系 统 显示 为 一 个 聚合 类 ， 边 界 类 作为 
系统 的 一 部 分 ， 显 示 在 该 聚合 类 的 内 部 。 处 于 系统 外 部 的 每 一 个 外 部 类 与 边界 类 之 间 都 有 一 个 一 
对 一 关联 。 因 此 ， 从 外 部 类 ( 如 软件 系统 上 下 文 类 图 所 描述 的 ) 开始 会 有 助 于 确定 边界 类 。 

从 “银行 系统 ”的 软件 系统 上 下 文 类 图 开始 ， 我 们 确定 每 一 个 外 部 类 与 一 个 边界 类 通 
А (图 8-7 )。 软 件 系统 被 描述 为 一 个 聚合 类 ， 包 含 了 连接 到 外 部 类 的 边界 类 。 在 这 个 应 用 
中 ， 有 三 个 设备 IO 边界 类 和 两 个 用 户 交 互 类 。 这 些 设备 ПО 边界 类 是 :“ 读 卡 器 接口 ”( Сага 
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Reader Interface )， 读 取 ATM 卡 ;“ 吐 钞 器 接口 ”( Cash Dispenser Interface )， 发 放 现金 ;“ 凭 


条 打印 机 接口 ”( Receipt Printer Interface )， 打 印 收据 。 


“客户 交互 ”( Customer Interaction ) 类 


是 一 个 用 户 交 互 类 ， 它 向 客户 显示 文本 信息 并 给 出 提示 ， 并 接收 客户 的 输入 。“ 操 作 员 交互 ” 
( Operator Interaction ) 类 向 АТМ 操作 员 提 供用 户 接口 ， 为 АТМ 机 补充 现金 。 对 于 每 一 个 


ATM 机 ， 每 个 边界 类 都 有 一 个 实例 。 













«software system» 


«external output 
device» 
ReceiptPrinter 






«external изег» 
ATMCustomer 
KeypadDisplay 


«ошри» 
CashDispenser 
Interface 


图 8-7 “银行 系统 ”的 外 部 类 和 边界 类 


86 ”实体 类 和 对 象 


实体 对 象 是 存储 信息 的 软件 对 象 。 实 体 对 象 是 实体 类 的 实例 ， 这 些 实体 类 的 属性 和 与 其 
他 实体 类 的 关系 在 静态 建 模 时 被 确定 ， 如 第 7 章 所 述 。 实 体 对 象 存储 数据 ， 并 通过 它们 提供 
的 操作 为 这 些 数据 提供 有 限 的 访问 。 在 某 些 情 况 下 ， 实 体 对 象 为 了 更 新 它 所 封装 的 信息 ， 可 


能 需要 访问 其 他 实体 对 象 。 


在 许多 信息 系统 的 应 用 中 ， 通 过 实体 对 象 封装 的 信息 被 存储 在 文件 或 数据 库 中 。 在 这 些 
情况 下 ， 实 体 对 象 是 持久 的 ， 这 意味 着 当 系统 关闭 然后 再 开启 时 ， 它 所 包含 的 信息 能 被 保持 。 
在 某 些 应 用 中 ， 比 如 实时 系统 ， 实 体 对 象 往 往 存储 在 主 存 中 。 这 些 问题 在 设计 阶段 被 解决 ， 


如 第 14 章 所 述 。 


“KF” (Account ) 类 是 银行 应 用 中 实体 类 的 一 个 例子 ( 图 8-8 )。 构 造型 «entity» 明确 地 标识 


ТЕЛЕ. Account 类 的 实例 是 实体 对 象 ( 如 图 8-8 
所 示 )， 这 个 实体 对 象 也 通过 构造 型 «entity» 来 标识 。 
Account 的 属性 有 “账户 编号 ”( accountNumber ) 和 
“余额 ”( balance )。 对 象 anAccount 是 一 个 持久 (长 
期 存在 的 ) 对 象 ， 通 过 实现 不 同 用 例 的 多 个 对 象 来 访 
问 。 这 些 用 例 包 括 在 各 种 АТМ 机 上 进行 账户 取款 、 
查询 和 转账 的 客户 用 例 ， 还 包括 人 类 出 纳 员 用 例 来 开 
设 和 关闭 账户 以 及 对 账户 进行 借 记 和 贷 记 。 上 账户 也 可 
以 被 那些 实现 为 客户 准备 月 结 单 并 打印 的 用 例 的 对 象 
来 访问 。 

“传感器 数据 ”( Sensor Data ) 类 是 传感器 监控 示 
例 中 的 实体 类 的 例子 ( 图 8-9 )。 这 个 类 存储 关于 模拟 





«entity» 

Account «entity» 
accountNumber: Integer anAccount 
balance: Real 


图 8-8 实体 类 与 对 象 示例 


«entity» | 

temperature 
ѕепѕогМате: String SensorData 
зепзогУаше: Real 


upperLimit: Real 
lowerLimit: Real 
alarmStatus: Boolean 





图 8-9 实体 类 和 对 象 示例 
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传感器 的 信息 ， 其 属性 有 “传感器 名 称 ”( sensorName ), “传感器 值 ”( sensorValue ), “ERR” 
(upperLimit ) “ F PIR” (lowerLimit) 以 及 “警报 状态 ”( alarmStatus )。“ 温 度 传感器 数据 ” 
( Temperature Sensor Data ) 对 象 是 该 类 的 一 个 实例 的 例子 。 


8.7 控制 类 和 对 象 


控制 对 象 提供 了 实现 一 个 用 例 的 对 象 的 总 体 协调 。 简 单 的 用 例 不 需要 控制 对 象 。 然 而 ， 
在 一 个 较 复 杂 的 用 例 中 ， 通 常 需要 控制 对 象 。 控 制 对 象 类 似 于 乐队 的 指挥 ， 它 指挥 ( 控制 ) 
其 他 参与 该 用 例 的 对 象 的 行为 ， 通 知 每 个 对 象 在 何 时 做 什么 。 依 赖 于 用 例 的 特性 ， 控 制 对 象 
可 以 是 状态 相关 的 。 控 制 对 象 有 多 个 种 类 ， 将 在 下 一 节 介 绍 。 


8.7.1 协调 者 对 象 


协调 者 对 象 是 做 出 总 体 决 策 的 对 象 ， 它 确定 了 相关 对 象 集合 的 总 体 顺序 安排 。 经 常 需要 协 
调 者 对 象 为 用 例 的 执行 提供 总 体 的 顺序 安排 。 它 做 出 总 体 决策 ， 并 决定 其 他 对 象 何 时 、 以 何 种 顺 
序 参 与 到 用 例 中 。 协 调 者 对 象 根 据 它 接收 到 的 输入 做 出 决策 ， 并 且 不 是 状态 相关 的 。 因 此 ， 由 协 
调 者 对 象 发 起 的 动作 只 取决 于 包含 在 传人 消息 中 的 信息 ， 而 不 依赖 于 系统 中 之 前 发 生 的 事情 。 

一 个 协调 者 类 的 例子 是 “银行 协调 者 ”( Bank Coordinator )， 如 图 8-10a 所 述 。 这 个 类 
的 实例 “银行 协调 者 ”对 象 接 收 来 自 客户 端 ATM 机 的 ATM 交易 。 根 据 交 易 类 型 , “银行 协 
调 者 ”将 该 交易 交 给 合适 的 交易 处 理 对 象 来 执行 该 交易 。 在 “银行 系统 ”里 ， 有 “取款 交易 
管理 器 ”( Withdrawal Transaction Manager ) 对 象 、 “转账 交易 管理 器 ”( Transfer Transaction 
Manager ) 对 象 、“ 查 询 交 易 管理 器 ”( Query Transaction Manager ) 对 象 以 及 “PIN 验证 交易 
管理 器 ”( PIN Validation Transaction Manager ) 对 象 ( 见 图 8-10b )。 


«coordinator» 
BankCoordinator 

«subsystem» 

: ATMClient 







4.1: Transfer 
Transaction 


1.1; PIN Validation 
Request 






Validation 
Response 



















«business logic» 
: PINValidation 
Transaction 

Manager 


«business logic» 
: Transfer 

Transaction 

Manager 


«business logic» 
: Withdrawal 
Transaction 

Manager 


«business logic» 
: Query 
Transaction 
Manager 










b) 
图 8-10 协调 者 类 和 对 象 示例 


一 种 协调 者 是 面向 服务 应 用 中 的 协调 者 对 象 ， 它 协调 在 一 个 用 户 交 互 对 象 和 一 个 或 多 
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个 服务 对 象 之 间 的 交互 。8.8.3 节 描 述 了 这 样 的 例子 。 
8.7.2 状态 相关 的 控制 对 象 


状态 相关 的 控制 对 象 是 一 种 在 不 同 状态 下 其 行为 有 变化 的 控制 对 象 。 有 限 状 态 机 用 于 定 
义 状态 相关 的 控制 对 象 ， 并 用 状态 图 来 描述 。 状 态 图 最 先 由 Harel (1988, 1998) 提出 ， 它 可 
以 是 平 的 ( 非 层次 的 ) 或 者 层次 的 ， 如 第 10 章 所 述 。 本 节 仅 给 出 状态 相关 的 控制 对 象 的 简要 
概述 ， 第 10、11 章 会 有 更 多 详细 的 介绍 。 

状态 相关 的 控制 对 象 接 收 引起 状态 转移 的 输入 事件 ， 并 产生 控制 其 他 对 象 的 输出 事件 。 
由 状态 相关 的 控制 对 象 产 生 的 输出 事件 不 仅 依 赖 该 对 象 接收 的 输入 ， 还 依赖 对 象 的 当前 状态 。 
状态 相关 的 控制 对 象 的 例子 是 “ATM 控制 ”( ATM Control) 对 象 (图 8-11 )， 它 是 用 “ATM 
控制 ”状态 图 的 方式 定义 的 。 在 该 例 中 ， 显 示 了 ATM Control 控制 了 另 两 个 输出 边界 对 象 : 
“Ж ТШЕП” ЯП “п ПП” 

在 一 个 控制 系统 里 ， 通 常 有 一 个 或 多 个 状态 相关 的 控制 对 象 ， 也 可 能 拥有 多 个 相同 类 型 
的 状态 相关 的 控制 对 象 。 尽 管 每 个 对 象 都 可 能 处 在 不 同 的 状态 ， 但 它们 都 执行 同一 个 有 限 状 
МА ( 描述 为 状态 图 ) 的 一 个 实例 。“ 银 行 系统 ”中 有 一 个 这 样 的 例子 ,“ 银 行 系统 ”有 多 个 
АТМ 机 ， 每 个 ATM 机 有 状态 相关 的 控制 类 АТМ Control 的 一 个 实例 ， 如 图 8-11 所 示 。 每 个 
“ATM 控制 ”对 象 执行 它 自己 的 “ATM 控制 ”状态 图 的 实例 ， 并 追踪 本 地 ATM 机 的 状态 。 
另 一 个 例子 来 自 “ 自 动 引 导 车 辆 系统 ”， 其 中 车 辆 的 控制 和 顺序 安排 是 由 状态 相关 的 控制 对 象 
“车 辆 控制 ”( Vehicle Control ) 的 方式 建 模 的 ， 并 且 通 过 状态 图 的 方式 来 定义 。 于 是 ， 每 辆 车 
都 有 一 个 车 辆 控制 对 象 。 更 多 的 关于 状态 相关 的 控制 对 象 的 信息 将 在 第 11 章 给 出 。 


8.7.3 计时 器 对 象 


计时 器 对 象 是 一 个 由 外 部 计时 器 (如 实时 时 钟 或 操作 系统 时 钟 ) 激活 的 控制 对 象 。 计 时 
器 对 象 要 么 自己 执行 某 个 动作 ， 要 么 激活 另 一 个 对 象 来 执行 期 望 的 动作 。 

图 8-12 给 出 了 计时 器 类 的 例子 :“ 报 告 计 时 器 ”( Report Timer )。 该 类 的 一 个 实例 一 一 计时 
器 对 象 Report Timer 一 一 通过 一 个 来 自 外 部 计时 器 “数字 时 钟 ”( Digital Clock ) 的 计时 器 事件 激 
活 。 然 后 ， 该 计时 器 对 象 发 送 一 个 “准备 ”( Prepare ) 消息 给 “周报 ”( Weekly Report) 对 象 。 


«timer» 
: ReportTimer 
«entity» 
: WeeklyReport 
b) b) 


图 8-11 ”状态 相关 的 控制 类 和 对 象 示例 图 8-12 “计时 器 ”类 和 对 象 示例 


estate dependent 
control» “iment 
ATMControl ReportTimer 
a) a) 










1: Timer Event 










«output» 
: CashDispenser 
Interface 


1: Dispense Cash 

т 
a 
2: Cash Dispensed 


«external timer» 
: DigitalClock 






«state dependent 
control» 
: ATMControl 













3: Print Receipt 
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— 
4: Receipt Printed 





: ReceiptPrinter 
Interface 
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8.8 应 用 逻辑 类 和 对 象 


本 节 描 述 了 三 种 应 用 逻辑 对 象 ， 即 业务 逻辑 对 象 、 算 法 对 象 和 服务 对 象 。 和 控制 对 象 一 样 ， 
应 用 逻辑 对 象 更 可 能 在 开发 动态 模型 时 被 考虑 ， 而 不 是 在 开发 初始 的 概念 静态 模型 时 被 考虑 。 


8.8.1 业务 逻辑 对 象 


业务 逻辑 对 象 定义 了 用 于 处 理 一 个 客户 端 请 求 的 特定 业务 的 应 用 逻辑 ， 其 目标 是 将 可 能 
相互 独立 变化 的 业务 规则 封装 〈 隐藏 ) 到 分 离 的 业务 逻辑 对 象 中 。 另 一 个 目标 是 将 业务 规则 
从 它们 操作 的 实体 数据 中 分 离 出 来 ， 因 为 业务 规则 可 以 独立 于 实体 数据 而 变化 。 通 常 是 业务 
逻辑 对 象 在 其 执行 期 间 访 问 各 种 实体 对 和 象 。 

业务 逻辑 对 象 只 在 特定 情况 下 需要 。 有 时 ， 有 以 下 两 种 选择 : 将 业务 逻辑 封装 到 分 离 的 
业务 逻辑 对 象 中 ， 或 者 ， 如 果 业 务 规则 足够 简单 ， 就 把 它 作 为 一 个 实体 对 象 的 操作 。 这 种 选 
择 的 指导 思想 是 ， 如 果 业 务 规则 只 有 通过 访问 两 个 或 者 更 多 的 实体 对 象 才能 执行 ， 就 应 该 有 
一 个 分 离 的 业务 逻辑 对 象 。 另 一 方面 ， 如 果 访 问 一 个 实体 对 象 就 足以 执行 业务 规则 ， 则 可 将 
它 作 为 该 对 象 的 一 个 操作 。 

业务 逻辑 类 的 一 个 例子 是 “取款 交易 管理 咒 ” 类 ， 如 图 8-13 所 示 。 该 类 的 一 个 实例 一 一 “ 取 
款 交 易 管 理 器 ”业务 逻辑 对 象 一 一 为 ATM 客户 的 取款 请 求 服务 ， 它 封装 了 处 理 АТМ 取款 请 
求 的 业务 规则 。 例 如 ， 第 一 个 业务 规则 是 客户 在 取款 后 必须 至 少 要 有 50 元 的 余额 ; 第 二 个 业 
务 规 则 是 客户 使 用 借 记 卡 取款 每 天 不 允许 超过 250 元 。 “取款 交易 管理 器 ”对 象 访问 “账户 ” 
对 象 ， 以 确定 第 一 个 业务 规则 是 否 满 足 。 它 访问 “ 借 记 卡 ”( Debit Card) 对 象 以 确定 第 二 个 
业务 规则 是 否 满足 ， 其 中 “ 借 记 卡 ”对 象 维护 了 当天 АТМ 客户 取款 的 实时 总 额 。 如 果 业 务 规 
则 有 一 个 不 满足 ， 则 取款 请 求 被 拒绝 。 

业务 逻辑 对 象 通常 必须 和 实体 对 象 交互 ， 以 便 执行 其 业务 规则 。 这 样 看 来 ， 它 类 似 于 协 
调 者 对 象 。 然 而 ， 业 务 逻 辑 对 象 的 主要 职责 是 封装 和 执行 业务 规则 ， 这 一 点 上 它 不 像 主要 职 
责 是 监督 其 他 对 象 的 协调 者 对 象 。 


8.8.2 算法 对 象 


算法 对 象 封装 间 题 域 中 使 用 的 算法 ， 该 种 对 象 在 实时 、 科 学 和 工程 领域 中 更 加 普遍 。 
当 有 问题 域 中 使 用 了 一 个 独立 于 其 他 对 象 而 变化 的 重要 算法 时 ， 就 要 使 用 算法 对 象 。 简 单 
的 算法 通常 是 实体 对 象 的 操作 ， 操 作 封 装 在 该 实体 类 内 的 数据 。 在 科学 和 工程 的 许多 领 
W, 算法 被 迭代 地 精 化 ， 因 为 它们 独立 于 它们 所 操纵 的 数据 而 改进 ( 例如， 为 改善 性 能 或 
精度 )。 

一 个 例子 是 列车 控制 系统 中 的 “巡航 器 ”( Cruiser ) 算法 类 。 该 类 的 一 个 实例 “巡航 器 ” 
对 象 通过 比较 当前 列车 速度 和 理想 巡航 速度 来 计算 应 如 何 对 速度 进行 调整 ( 图 8.14 )。 该 算法 
是 复杂 的 ， 因 为 它 必 须 在 需要 时 提供 对 列车 的 平缓 加 速 或 减速 ， 使 得 对 乘客 的 影响 最 小 化 。 

算法 对 象 经 常 封装 了 计算 其 算法 所 需要 的 数据 。 这 些 数据 可 以 是 初始 化 数据 、 中 间 结 果 
Жеў нй ВИНОВЕ (С 例如 最 大 值 或 最 小 值 )。 

算法 对 象 必须 频繁 地 和 其 他 对 象 交 互 ， 以 便 执 行 算法 ( 如 Cruiser )。 这 样 看 来 ， 它 类 似 
于 一 个 协调 者 对 象 。 然 而 ， 算 法 对 象 的 主要 职责 是 封装 和 执行 算法 ， 这 一 点 上 它 不 像 主要 职 
责 是 监督 其 他 对 象 的 协调 者 对 象 。 
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b) 
Е 8-13 ”业务 逻辑 类 和 对 象 示例 
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图 8-14 算法 类 和 对 象 示例 
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8.8.3 ARB WR 


服务 对 象 是 为 其 他 对 象 提供 服务 的 对 象 ， 它 们 通常 在 面向 服务 的 架构 和 应 用 中 提供 ， 如 
第 16 章 所 述 。 客 户 端 对 象 能 从 服务 对 象 请 求 一 个 服务 ， 服 务 对 象 将 做 出 响应 。 服 务 对 象 绝 不 
会 发 起 一 个 请 求 ; 然而 ， 在 响应 服务 请 求 时 ， 它 可 能 会 寻求 其 他 服务 对 象 的 帮助 。 服 务 对 象 
在 面向 服务 的 架构 中 扮演 重要 的 角色 ， 尽 管 它们 也 被 用 在 其 他 的 架构 中 ， 例 如 客户 端 /服务 
器 体系 结构 和 基于 构件 的 软件 体系 结构 。 服 务 对 象 可 能 封装 了 它 需 要 用 来 服务 客户 端 请 求 的 
数据 ， 或 者 访问 其 他 封装 了 该 数据 的 实体 对 象 。 

服务 类 的 一 个 例子 是 图 8-15a 给 出 的 “目录 服务 ”( Catalog Service ) 类 。 图 8-15b 展示 了 
执行 该 类 的 实例 (“目录 服务 ”对 象 ) 的 例子 。“ 目 录 服 务 ” 对 象 为 在 供应 商 目 录 中 查看 各 种 
不 同 的 目录 商品 和 从 目录 中 选择 商品 提供 支持 “客户 协调 者 ”( Customer Coordinator ) 辅助 
“客户 交互 ”( Customer Interaction ) 对 象 找 到 一 个 由 “目录 服务 ”( Catalog Service ) 对 象 提供 
的 供应 商 目 录 ， 并 从 目录 中 做 出 选择 。 除 了 服务 类 和 对 象 ， 协 调 者 类 和 对 象 也 常用 在 面向 服 
务 的 架构 和 应 用 中 ， 如 第 16 章 所 述 。 


«service» 
CatalogService 
a) 


2: Catalog Request 
1; Customer Input Ван 
«user interaction» = «coordinator» 
: CustomerInteraction <— aCustomerCoordinator 


6: Catalog Output 5: Catalog Info 














aCustomer 


3: Catalog Request | 1 4: Catalog Info 


«service» 
: CatalogService 


b) 
Р 8-15 ”服务 类 和 对 象 示例 


8.9 总 结 


本 章 描述 了 如 何 确 定 系 统 中 的 软件 对 象 和 类 ， 提 供 了 对 象 和 类 的 构造 标准 ， 并 通过 使 用 
构造 型 对 对 象 和 类 分 类 。 其 重点 是 那些 要 在 真实 世界 中 发 现 的 问题 域 对 象 和 类 上 ， 而 不 是 那 
些 在 设计 时 确定 的 解 域 对 象 。 在 动态 交互 建 模 ( 如 第 9、11 章 所 述 ) 期 间 ， 对 象 和 构造 标准 
通常 依次 应 用 于 每 个 用 例 上 ， 以 确定 参与 到 每 个 用 例 中 的 对 象 。 然 后 ， 对 象 之 间 的 交互 序列 
被 确定 。 子 系统 构造 标准 在 第 13 章 描述 。 每 个 类 所 提供 操作 的 设计 在 第 14 章 描述 。 


练习 
选择 题 ( 每 道 题 选择 一 个 答案 ) 
1. 什么 是 边界 对 象 ? 


(a) 外 部 对 象 (b ) 储存 数据 的 对 象 
(с) 和 外 部 对 象 通信 的 对 象 (4) 控制 其 他 对 象 的 对 象 


2. 什么 是 控制 对 象 ? 

(a) 与 其 他 对 象 相 关 的 对 象 
Co) 控制 其 他 对 象 的 对 象 

3. 什么 是 状态 相关 的 控制 对 象 ? 
(а) 与 状态 机 相关 的 对 象 

(с) 控制 状态 机 的 对 象 

4. 什么 是 协调 者 对 象 ? 

(a) 管理 器 对 象 

(с) 做 决策 的 对 象 

5. 如 何 从 上 下 文 图 确定 边界 类 ? 
(a) 通过 观察 它 

(с) 通过 确定 和 外 部 类 通信 的 软件 类 
6. 什么 是 计时 器 对 象 ? 

(а) 外 部 时 钟 

(с) 被 外 部 计时 器 唤醒 的 对 象 
7. 类 构造 标准 对 什么 有 帮助 ? 
(a) 将 一 个 应 用 构造 为 多 个 类 
(c) 定义 类 的 关联 

8. 应 用 类 的 分 类 过 程 类 似 于 什么 ? 
(a) 图 书馆 中 对 书 分 类 

(с) 在 学 校 中 找到 教室 

9. 类 构造 中 的 构造 型 的 目的 是 什么 ? 
(a) 根据 类 构造 标准 对 类 打 标 签 
(с) 区 分 外 部 对 象 和 软件 对 象 
10. 什么 是 业务 逻辑 对 象 ? 

(а) 用 在 业务 应 用 中 的 对 象 
(с) 对 象 的 内 部 逻辑 
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(b) 和 外 部 对 象 通信 的 对 象 
(а) 被 其 他 对 象 控 制 的 对 象 


(b) 和 状态 机 通信 的 对 象 
Cd) 执行 状态 机 的 对 象 


(b) 根据 状态 机 做 出 决策 的 对 象 
(4) 决定 和 哪个 实体 对 象 交互 的 对 象 


(b) 通过 选择 上 下 文 图 中 的 外 部 类 
(а) 通过 在 硬件 和 软件 类 之 间 绘 制 边 界 


(b) 内 部 时 钟 
(а) 和 时 钟 交互 的 对 象 


(b) 定义 类 的 属性 
(4) 定义 类 的 操作 


(b) 决定 一 本 书 需要 多 少 副本 
(4) 标识 学 校 有 哪些 实验 室 


(b) 标识 属于 相同 类 的 对 象 
(4) 标识 两 个 类 之 间 的 关联 


(b) 定义 特定 业务 应 用 人 逻辑 的 对 象 


(4) 确定 一 个 客户 端 请 求 是 否 符合 逻辑 的 业务 对 象 。 [31 


第 9 章 | 
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动态 交互 建 模 





动态 建 模 提供 了 系统 的 一 种 视图 ， 其 中 考虑 了 控制 和 顺序 安排 该 视图 要 么 在 一 个 对 象 
中 (通过 一 个 有 限 状 态 机 的 方式 ), 要 人 么 在 对 象 之 间 (通过 对 对 和 象 交互 的 分 析 )。 本 章 曾 述 了 
对 和 象 之 间 的 动态 交互 。 

动态 交互 建 模 是 基于 在 用 例 建 模 阶段 开发 的 用 例 的 实现 进行 的 。 对 于 每 一 个 用 例 来 说 ， 
有 必要 去 确定 每 一 个 参与 的 对 象 是 怎样 在 用 例 中 和 其 他 对 象 进行 动态 交互 的 。 在 第 8 章 中 描 
述 的 对 象 结 构 组 织 准 则 能 够 用 于 确定 参与 到 每 一 个 用 例 中 的 对 象 。 本 章 论述 对 于 每 一 个 用 例 ， 
如 何 开发 一 个 交互 图 来 描绘 参与 到 该 用 例 中 的 对 象 和 这 些 对 象 之 间 的 消息 序列 。 这 种 交互 以 
通信 图 或 顺序 图 来 展现 ， 同 时 还 会 在 消息 序列 描述 中 加 入 对 于 每 个 对 象 交 互 的 叙述 性 描述 。 
请 注意 ， 本 章 中 所 有 的 系统 都 是 指 软件 系统 。 

本 章 先 描 述 了 使 用 通信 图 和 顺序 图 进行 对 象 交 互 建 模 ， 然 后 描述 了 这 两 种 图 如 何 运 用 于 
动态 交互 建 模 。 接 下 来 ， 阐 述 了 动态 交互 建 模 方法 的 细节 ， 来 确定 对 象 之 间 是 如 何 协作 的 。 本 
章 还 阐述 了 无 状态 的 动态 交互 建 模 ， 也 称 作 基本 的 动态 交互 建 模 。 第 11 章 将 会 阐述 状态 相关 的 
动态 交互 建 模 ， 和 无 状态 的 动态 交互 建 模 不 同 的 是 ， 它 引入 了 由 状态 图 控制 的 状态 相关 的 通信 。 

9.1 节 概 述 了 对 象 交 互 建 模 并 描述 了 两 种 交互 图 : 通信 图 和 顺序 图 。9.2 чш Т Жн 
中 的 消息 序列 编号 问题 。 9.3 节 介 绍 了 动态 交互 建 模 。9.4 节 描 述 了 无 状态 的 动态 交互 建 模 。9.5 
节 给 出 了 无 状态 动态 交互 建 模 的 两 个 例子 。 


91 对 象 交互 建 模 


对 于 每 一 个 用 例 而 言 ， 参 与 其 中 的 对 象 总 是 动态 地 和 其 他 对 象 合 作 ， 如 本 节 下 文 所 言 ， 
我 们 可 以 用 一 个 UML 通信 图 或 者 是 一 个 UML 顺序 图 来 对 其 进行 展示 。 


9.1.1 通信 图 


通信 图 是 一 种 UML 交互 图 ， 它 从 动态 的 视角 描绘 了 一 组 对 象 是 怎样 通过 对 象 间 消息 传 
递 来 进行 相互 交互 的 。 在 分 析 建 模 的 过 程 中 ， 每 一 个 用 例 对 应 一 张 通信 图 ， 只 有 参与 了 这 
个 用 例 的 对 象 才 会 被 显示 在 通信 图 上 。 在 通信 图 中 ， 对 象 之 间 的 消息 发 送 序列 是 由 消息 序 
列 的 编号 来 描述 的 。 通 信 图 中 的 消息 序列 应 该 和 用 例 中 描述 的 参与 者 和 系统 之 间 的 交互 顺 
序 相 对 应 。 

我 们 可 以 用 应 急 监控 系统 案例 研究 中 的 “查看 警报 ”( View Alarms) 用 例 (图 9-1 ) Ж 
展示 如 何 用 一 个 通信 图 来 描绘 用 例 中 的 对 象 ， 在 这 个 例子 中 ， 监 控 操 作 员 需要 查看 未 处 理 的 
警报 。 在 这 个 简单 用 例 的 通信 图 (图 9-2) 上 只 有 两 个 对 象 : 一 个 用 户 交 互 对 象 和 一 个 服务 
对 象 。 用 户 交 互 对 象 被 称 为 “操作 员 交 互 ”( Operator Interaction )， 服 务 对 象 被 称 为 “警报 服 
务 ”( Alarm Service )。 

这 个 用 例 的 通信 图 描绘 了 用 户 交 互 对 象 ( 操作 员 交 互 )， 向 服务 对 象 ( 警报 服务 ) 发 出 一 
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个 请 求 ， 该 服务 对 象 收 到 请 求 后 做 出 响应 ( 见 图 9-2 )。 


| 


Monitoring 
Operator 
图 9-1 用 例 “ 查 看 警报 ”的 用 例 图 
А1: Operator 
Request 
—> 
= «user interaction» 
: OperatorInteraction 
: Monitoring А1.3: Display 
Operator Info 






А1.1: Alarm 
Request А1.2: Alarm 


«service» 
: AlarmService 


图 9-2 FAB) “Aa” AGH aA 
9.1.2 ”顺序 图 


对 象 之 间 的 交互 也 可 以 用 顺序 图 来 表示 ， 顺 序 图 按时 间 顺 序 展 示 了 对 象 之 间 的 交互 。 一 
个 顺序 图 展示 了 所 有 参与 交互 的 对 象 以 及 它们 之 间 消 息 来 往 的 顺序 。 顺 序 图 也 可 以 用 来 描述 
循环 和 迭代。 顺序 图 和 通信 图 虽然 描述 的 是 类 似 的 信息 (尽管 不 是 完全 一 致 )， 但 是 用 的 却 是 
不 同 的 方法 。 通 常 我 们 要 么 使 用 通信 图 ， 要 么 使 用 顺序 图 来 对 系统 进行 动态 描述 ， 而 不 是 两 
种 同时 使 用 。 

因为 顺序 图 描述 的 是 使 用 从 上 到 下 的 顺序 来 对 消息 序列 进行 顺序 显示 ， 因 此 对 顺序 图 中 
的 消息 没有 必要 进行 编号 。 在 下 面 的 例子 中 ， 为 了 使 顺序 图 和 通信 图 的 消息 顺序 对 应 ， 我 们 
也 在 顺序 图 上 对 消息 进行 了 编号 。 

图 9-3 用 “查看 警报 ”用 例 展示 了 一 个 顺序 图 。 这 个 顺序 图 中 传达 了 和 通信 图 一 致 的 信 
息 ， 如 图 9-2 所 示 。 


913 对象 交互 建 模 的 分 析 和 设计 决策 


在 分 析 模 型 中 ,消息 表示 对 象 之 间 的 信息 传递 。 利 用 交互 图 (通信 图 或 顺序 图 ) 可 以 帮 
助 确定 对 象 的 操作 ， 因 为 消息 的 抵达 通常 会 调用 操作 。 在 COMET 里 ， 分 析 建 模 的 重点 是 捕 
获 对 象 之 间 传 递 的 信息 ， 而 不 是 被 调用 的 操作 。 在 设计 过 程 中 ， 我 们 可 能 会 决定 让 到 达 同 一 
个 对 象 的 两 个 不 同 消息 去 调用 不 同 的 操作 ， 也 可 能 会 调用 一 个 相同 的 操作 ， 只 是 把 消息 名 作 
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为 操作 的 参数 。 然 而 ， 这 些 决 策 需 要 推迟 到 设计 阶段 来 进行 。 同 样 应 该 被 推迟 到 设计 阶段 的 
决策 还 有 对 象 ( 同步 或 异步 ) 间 传 递 的 消息 类 型 。 在 分 析 阶 段 ， 所 有 在 对 象 之 间 传 递 的 信息 
都 是 简单 的 消息 。 


: Monitoring 
Operator i i 
р «user interaction» «service» 
: Operator : i 
| : AlarmService 
Interaction 


1 
1 
1 
| | 
| 

| At: Operator Request | 
юке | 
| 
| 


1 А1.1: Alarm Request 


| 
| 
1 
| 
1 
1 
1 
1 А1.2: Alarm 
e nN 
| 
| 

А1.3: Display Info | 

4 





1 
Џ 
| 
1 
1 
| 
| 
1 
| 
| 
1 
1 
上 


图 9-3 ”用例 “ 查 看 警报 ”的 顺序 图 
在 分 析 阶 段 ， 不 会 确定 一 个 对 象 是 主动 的 还 是 被 动 的 ， 这些 决 定 也 被 推迟 到 设计 阶段 。 
9.1.4 顺序 图 和 通信 图 对 比 


无 论 是 顺序 图 还 是 通信 图 都 可 以 用 来 描绘 对 象 交互 和 对 象 间 消 息 传 递 的 序列 。 顺 序 图 可 
以 通过 顺序 展示 的 形式 很 清晰 地 显示 对 象 间 消 息 传递 的 序列 ， 但 要 想 在 顺序 图 上 看 清 对 象 之 
间 是 如 何 关联 的 却 较为 困难 。 另 外 ， 如 果 使 用 了 循环 语句 ( 例如 do-while 语句 ) 或 者 是 判定 
语句 〈 例如 if-then-else 语句 )， 则 会 降低 对 象 交 互 顺 序 的 可 读 性 。 

通信 图 展示 了 对 象 的 布局 ， 尤 其 显示 了 对 象 之 间 是 如 何 关联 的 。 两 种 交互 图 都 可 以 用 来 
展示 消息 序列 。 因 为 在 通信 图 上 展示 消息 序列 的 直观 性 要 比 在 顺序 图 上 展示 的 效果 差 ， 所 以 
我 们 需要 在 通信 图 上 对 消息 序列 进行 编号 。 不 过 即使 在 通信 图 上 编 了 号 ， 在 阅读 消息 序列 的 
时 候 也 要 比 在 顺序 图 上 花 更 多 的 时 间 。 另 一 方面 ， 如 果 一 个 交互 牵涉 了 很 多 对 象 ， 顺 序 图 就 
更 难 阅读 了 。 这 些 图 可 以 被 压缩 到 一 页 之 中 ， 也 可 以 横 跨 多 个 页 面 。 

COMET 之 所 以 偏好 使 用 通信 图 而 不 是 顺序 图 ， 是 因为 从 分 析 阶 段 过 渡 到 设计 阶段 中 的 
一 个 很 重要 的 步骤 就 是 去 整合 通信 图 的 信息 来 创建 初期 的 软件 系统 体系 结构 ， 这 个 内 容 会 在 
第 13 章 中 提 到 。 利 用 通信 图 来 进行 整合 要 比 用 顺序 图 容易 很 多 。 如 果 分 析 是 从 顺序 图 开始 的 
话 ， 那 么 在 进行 整合 之 前 还 要 把 每 张 顺序 图 都 转换 成 通信 图 。 然 而 ， 有 时 利用 顺序 图 也 是 非 
常 方 便 的， 尤其 是 面 对 一 些 非常 复杂 或 大 规模 的 对 象 交 互 时 更 是 如 此 。 


9.1.5 ”用例 和 场景 


场景 是 用 例 的 一 条 特定 路 径 。 因 此 ， 一 个 交互 图 上 特定 的 消息 序列 其 实 描绘 的 是 一 个 场 
景 而 不 是 一 个 用 例 。 要 想 把 一 个 用 例 的 所 有 可 能 路 径 都 显示 出 来 通常 需要 超过 一 张 交互 图 。 

利用 给 出 的 条 件 ， 可 以 把 不 同 的 可 能 情况 都 描绘 在 一 张 交互 图 上 ， 从 而 可 以 在 一 张 交互 
图 上 把 整个 用 例 都 描绘 出 来 。 但 是 ， 这 样 复 杂 的 交互 图 却 往往 难以 读 懂 。 在 实践 中 ， 用 一 张 
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交互 图 来 描述 一 个 单独 的 场景 通常 会 更 加 清晰 。 
同样 ， 利 用 有 循环 结构 和 分 支 结构 的 顺序 图 ， 也 可 以 把 整个 用 例 的 所 有 交互 序列 描绘 出 
Жж, 包括 主 序列 和 其 他 可 替换 序列 。 更 详细 的 内 容 会 在 第 9.5 节 中 讨论 。 


9.1.6 通用 和 实例 形式 的 交互 图 


交互 图 (顺序 图 或 通信 图 ) 的 两 种 形式 分 别 是 通用 形式 和 实例 形式 。 实 例 形式 用 来 详 
细 地 描述 一 个 特定 的 场景 ， 把 一 个 可 能 的 对 象 实例 间 的 交互 序列 描绘 出 来 。 而 通用 形式 则 
是 用 来 描述 参与 交互 的 对 象 之 间 所 有 可 能 的 交互 关系 ， 因 此 会 包含 循环 、 分 支 和 条 件 。 交 
互 图 的 通用 形式 既 可 以 用 来 描述 主 序列 ， 也 可 以 用 来 描述 其 他 可 替换 用 例 的 序列 。 实 例 形 
式 的 交互 图 用 来 描绘 一 个 特定 的 场景 ， 这 个 场景 通常 是 用 例 中 的 一 个 实例 。 使 用 实例 形式 
的 交互 图 需要 多 张 交 互 图 来 描绘 一 个 给 定 的 用 例 ， 其 数量 取决 于 这 个 用 例 中 描述 了 多 少 种 
可 能 的 备 选 情况 。 实 例 形式 和 通用 形式 的 交互 图 的 例子 ， 包 括 通信 图 和 顺序 图 ， 都 会 在 第 
9.5 节 中 讨论 。 

对 于 除非 是 最 简单 的 用 例 的 大 部 分 用 例 ， 实 例 形式 的 交互 图 会 比 通用 形式 的 交互 图 更 加 
清晰 。 当 几 种 备 选 情况 都 在 一 张 图 上 描绘 的 时 候 ， 这 些 图 很 容易 就 会 变 得 非常 复杂 。 在 实例 
形式 的 顺序 图 上 ， 因 为 时 间 顺 序 直接 体现 在 页 面 上 ， 所 以 很 容易 跟踪 消息 序列 。 但 是 ， 通 用 
形式 的 顺序 图 一 一 具 有 循环 、 分 支 和 条 件 的 情况 一 一 就 不 是 这 人 么 简单 的 了 ， 它 会 把 整个 消息 
序列 变 得 非常 难以 理解 。 


9.2 ”交互 图 上 的 消息 序列 编号 


通信 图 或 者 顺序 图 上 的 消息 都 会 被 赋予 消息 序列 编号 。 本 节 中 ， 我 们 会 对 消息 序列 编号 
提供 一 些 指 导 。 这 些 指 导 都 遵循 了 通用 的 UML 惯例 ; 除 此 以 外 ， 它 们 也 会 被 扩展 以 更 好 地 解 
决 并 发 、 备 选 情况 和 庞大 消息 序列 的 问题 。 在 本 章 后 面 给 出 的 示例 中 (第 9.5 节 中 的 更 多 例 
T) 以 及 第 20 章 到 第 24 章 中 的 案例 研究 中 给 出 的 示例 都 将 遵循 这 些 惯例 。 


9.2.1 交互 图 上 的 消息 标签 


顺序 图 或 者 交互 图 上 的 消息 标签 遵循 以 下 的 语法 ( 这 里 只 介绍 消息 标签 中 与 分 析 阶 段 相 
关 的 部 分 ): 

[序列 表达 式 ]: 消息 名 称 ( 参数 列表 ) 

其 中 ,序列 表达 式 包含 了 消息 序列 的 编号 和 一 个 重 现 的 指示 髓 。 

е 消息 序列 编号 。 消 息 序列 编号 的 构成 如 下 : 第 一 个 消息 序列 编号 代表 着 通信 图 上 
某 个 消息 序列 的 事件 的 起 始 。 典 型 的 消息 序列 形式 如 下 : 1, 2, 3,…; Al, А2, 
A3，…。 一 个 更 加 精细 的 消息 序列 可 以 用 Dewey 分 类 系统 来 描述 ， 例 如 Al.1.1 紧 
跟着 Al1.1， 然 后 是 A1.2。 在 Dewey 系统 中 ， 一 个 典型 的 消息 编号 序列 是 A1，Al1.1， 
А1.1.1, Al.2. 

© 循环 。 循 环 的 部 分 是 可 选 的 ， 它 代表 了 条 件 或 迭代 的 执行 。 循 环 的 部 分 代表 了 当 满 足 
一 定 条 件 的 情况 下 会 发 送 零 条 或 多 条 信息 。 

ө *[ 迭代 语句 ]。 在 一 个 消息 序列 编号 后 面 加 上 一 个 星 号 (* ) 表示 要 发 送 超过 一 条 的 
消息 。 这 个 可 选 的 迭代 语句 是 用 来 指定 重复 的 执行 ， 例 如 [ := Ln]。 一 个 在 消息 序 
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列 编号 后 加 上 星 号 来 代表 迭代 的 例子 是 3*。 
о [条 件 语句 ]。 放 在 中 括号 里 的 一 个 条 件 用 来 指示 一 个 分 支 条 件 。 这 个 可 选 的 条 件 
语句 是 用 来 指定 分 支 结构 的 ， 例 如 [x < п], 意味 着 只 有 当 这 个 条 件 判 断 为 真 的 时 
候 ， 消 息 才 会 被 发 送出 去 。 例 如 ， 跟 在 一 个 消息 序列 编号 后 面 的 条 件 4[x < п] 和 
S[Normal] 就 是 有 条 件 的 消息 传递 的 例子 。 在 两 种 情况 下 ， 只 有 分 别 当 条 件 满足 的 
时 候 ， 消 息 才 会 被 发 送出 去 。 
。 消息 名 称 。 消 息 名 称 是 指定 的 。 
• 参数 列表 。 消 息 的 参数 列表 是 可 选 的 ， 它 指定 了 所 有 要 随 着 消息 一 起 发 送 的 参数 。 
发 送出 去 的 消息 的 返回 值 是 可 选 的 。 但 是 ， 在 分 析 阶 段 建议 只 使 用 一 些 简 单 的 消息 ， 不 
要 带 返 回 值 ， 把 应 该 使 用 哪 种 消息 类 型 这 个 问题 推迟 到 设计 阶段 去 考虑 。 


9.2.2 ”交互 图 上 的 消息 序列 编号 


在 一 张 支持 一 个 用 例 的 通信 图 上 ， 对 象 参与 每 一 个 用 例 的 序列 是 通过 消息 序列 编号 来 描 
述 的 。 一 个 用 例 的 消息 序列 编号 的 形式 如 下 : 

[第 一 个 可 选 的 字母 序号 ][ 数字 序号 ][ 第 二 个 可 选 的 字母 序号 ] 

第 一 个 可 选 的 字母 序号 是 一 个 可 选 的 用 例 ID ， 它 标示 了 一 个 用 例 是 一 个 特定 的 具体 的 用 
例 还 是 一 个 抽象 的 用 例 。 第 一 个 字母 是 一 个 大 写字 母 ， 后 面 如 果 需 要 描述 性 用 例 ID 的 话 ， 还 
可 能 跟着 一 个 或 多 个 大 写 或 者 小 写字 母 。 

最 简单 的 消息 序列 的 形式 是 用 一 个 整数 序列 表示 ， 例 如 М1, М2 和 M3。 但 是 ， 在 一 个 
有 着 多 个 外 部 参与 者 输入 的 交互 系统 当中 ， 带 有 一 个 小 数 的 数字 序列 可 能 会 更 有 用 ， 也 就 是 
说 ， 用 整数 来 表示 外 部 事件 ， 而 用 跟 在 后 面 的 小 数 表示 内 部 事件 。 例 如 ， 如 果 参 与 者 的 输入 
被 指定 为 A1，A2 和 A3， 则 完整 的 通信 图 消息 序列 应 当 是 A1，Al1.1，Al1.2，Al1.3，…，A2， 
A2.1，A2.2，…，A3，A3.1，A3.2，.…。 

一 个 例子 是 V1， 其 中 V 代表 用 例 ， 数 字 代表 支持 用 例 的 通信 图 的 消息 序列 。 发 送 第 一 
个 消息 的 对 象 V 是 这 个 用 例 基于 通信 的 启动 者 。 因 此 ， 在 图 9-2 和 图 9-3 分 别 所 示 的 通信 图 
和 顺序 图 上 ， 参 与 者 的 输入 都 是 从 V1 开始 的 。 后 续 的 消息 编号 是 V1.1，V1.2 和 V1.3， 如 果 
对 话 还 将 继续 的 话 ， 下 一 个 参与 者 的 输入 将 从 V2 开始 编号 。 


9.2.3 ”并 发 和 可 替换 的 消息 序列 


第 二 个 在 消息 序列 编号 中 可 选 的 字母 序号 是 用 来 描述 一 些 特殊 的 分 支 情况 : 要 么 是 并 发 
情况 ， 要 么 是 备 选 情 况 。 

并 发 的 消息 也 可 以 在 一 个 通信 图 中 描绘 ， 一 个 小 写 的 字母 表示 一 个 并 发 序列 ， 也 就 是 说 ， 
被 指定 为 A3 和 A3a 的 序列 是 并 发 的 序列 。 例 如 ， 消 息 A2 到 达 对 象 久 可 能 会 导致 对 象 义 同 
时 间 对 象 Y 和 了 Z 发 送 了 消息 ， 并 导致 它们 并 行 地 执行 。 为 了 阐明 这 个 例子 中 的 并 发 情况 ， 假 
设 被 发 送 到 对 象 Y 的 消息 被 指定 为 A3， 被 发 送 到 对 象 Z 的 消息 被 指定 为 A3a。A3 序列 中 
后 续 的 消息 被 指定 为 A4，A5，A6，…， 而 Ala 序列 的 后 续 消息 会 被 指定 为 A3a.1，A3a.2， 
A3a.3， 如 此 继续 。 因 为 A3a 的 后 续 序 列 编号 更 加 复杂 ， 所 以 用 АЗ 来 表示 主 消息 序列 ， 用 
АЗа, A3b 这 样 的 编号 来 表示 支持 性 消息 序列 。 另 外 一 种 显示 两 个 并 发 序列 的 方法 是 避免 使 用 
A3， 而 是 直接 使 用 A3a 和 A3b， 当 然 ， 这 种 方法 也 有 问题 ， 如 果 Аза 又 产生 了 两 个 新 的 并 发 
序列 ， 整 个 编号 模式 将 变 得 非常 复杂 ， 因 此 更 加 推荐 的 是 第 一 种 方法 。 
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可 替换 消息 序列 用 消息 之 后 跟着 的 条 件 来 描述 。 一 个 大 写字 母 用 来 命名 一 个 可 替换 
的 分 支 。 例 如 ， 主 分 支 可 能 被 标记 为 1.4[Normall]， 另 外 不 常用 到 的 分 支 则 可 能 被 标记 为 
1.4A[Error]。 正 常 ( Normal ) 分 支 的 消息 序列 编号 可 能 是 1.4[Normal]，1.5，1.6， 如 此 继续 。 
可 替换 分 支 的 消息 序列 编号 可 能 是 1.4A[Error]，1.4A.1，1.4A.2， 如 此 继续 。 


9.24 消息 序列 描述 


消息 序列 描述 是 一 种 支持 性 的 文档 ,一般 和 交互 图 一 起 提出 。 它 经 常 被 当做 是 动态 模型 
的 一 部 分 来 开发 ， 描 述 的 是 分 析 模 型 对 象 是 如 何 参 与 到 交互 图 中 描绘 的 每 一 个 用 例 中 的 。 消 
息 序列 描述 是 一 个 叙述 性 描述 ， 描 述 了 当 每 个 消息 到 达 通 信和 图 或 顺序 图 上 的 目标 对 象 时 会 发 
生 什么 。 消 息 序列 描述 使 用 通信 图 上 的 消息 序列 编号 。 它 描述 了 从 源 对 象 到 目标 对 象 的 消息 
序列 发 送 以 及 当 一 个 目标 对 象 收 到 一 个 消息 的 时 候 会 做 些 什 么 。 消 息 序列 描述 通常 提供 了 额 
外 的 信息 ， 这 些 信息 在 对 象 交 互 图 上 没有 被 描绘 出 来 。 例 如 ， 每 次 访问 一 个 实体 对 象 时 ， 消 
息 序列 描述 可 以 提供 额外 的 信息 ， 比 如 对 象 参考 的 属性 有 哪些 。 

消息 序列 描述 的 例子 在 9.5 节 中 给 出 。 


9.3 动态 交互 建 模 


动态 交互 建 模 是 一 种 交互 式 的 策略 ， 它 用 来 帮助 确定 分 析 模 型 对 象 之 间 是 怎样 交互 来 支 
持 用 例 的 。 动 态 交 互 建 模 在 每 一 个 用 例 中 被 执行 。 第 一 次 尝试 是 用 第 8 章 中 描述 的 对 象 结构 
组 织 准则 来 确定 用 例 中 参与 的 对 象 。 接 着 分 析 这 些 对 象 是 怎样 合作 来 执行 用 例 的。 这 个 分 析 
可 能 会 展示 出 需要 额外 对 象 和 / 或 定义 额外 的 交互 。 

动态 交互 建 模 可 能 是 状态 相关 或 者 是 无 状态 的 ， 这 取决 于 对 象 通 信 是 否 是 状态 相关 的 。 
本 章 主要 描述 无 状态 的 动态 交互 建 模 。 状 态 相 关 的 动态 交互 建 模 将 在 第 11 章 中 描述 。 
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无 状态 的 动态 交互 建 模 方法 的 主要 步骤 如 下 : 从 用 例 开始 ， 接 着 考虑 实现 用 例 所 需要 的 
对 象 ， 然 后 再 确定 对 象 之 间 消 息 通 信 的 序列 。 


1. 开发 用 例 模型 。 这 个 步骤 在 第 6 章 中 已 经 有 过 描述 。 对 于 动态 建 模 来 说 ， 考 虑 每 
一 个 主要 参与 者 和 系统 之 间 的 每 一 个 交互 。 记 住 ， 参 与 者 和 系统 之 间 的 交互 是 从 一 个 外 部 
输入 开始 的 。 系 统 对 这 个 输入 进行 一 些 内 部 执行 并 做 出 响应 ， 通 常 是 提供 一 个 系统 输出 。 
参与 者 输入 的 序列 和 系统 响应 都 会 在 用 例 中 描述 。 从 开发 在 用 例 的 主 路 径 中 描述 的 场景 的 
通信 序列 开始 。 考 虑 每 一 个 序列 中 的 参与 者 和 系统 的 交互 。 

2. 确定 在 实现 用 例 时 所 需 的 对 象 。 这 步 需要 使 用 对 象 结构 组 织 准则 (LSE) 来 


确定 在 实现 用 例 时 所 需 的 对 象 ， 包 括 了 边界 对 象 ( 下 述 2а) 和 内 部 软件 对 象 ( 下 述 2b )。 
2а. 确定 边界 对 象 。 考 虑 参与 用 例 的 参与 者 ， 确 定 外 部 对 象 《 系 统 的 外 部 ， 通 过 外 部 
对 象 参 与 者 和 系统 进行 通信 ) 和 软件 对 象 ( 收 到 参与 者 输入 )。 
从 考虑 外 部 对 象 输入 到 系统 的 输入 开始 。 对 于 每 一 个 外 部 输入 事件 ， 考 虑 处 理事 件 
所 需要 的 软件 对 象 。 如 果 输 入 事件 是 来 自 一 个 外 部 对 象 的 话 ， 我 们 需要 一 个 软件 边界 对 象 
(例如 一 个 输入 对 象 或 者 是 一 个 用 户 交互 对 象 )。 在 接收 到 外 部 输入 的 时 候 ， 边 界 对 象 通常 
会 处 理 和 发 送 消息 给 内 部 对 象 。 
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2b. 确定 内 部 软件 对 象 。 考 虑 用 例 的 主 序列 。 利 用 对 象 结构 组 织 准则 来 首先 确定 参与 
用 例 的 内 部 软件 对 象 ， 例 如 控制 对 象 或 者 是 实体 对 象 。 

З. 确定 消息 通信 序列 。 对 于 每 一 个 从 外 部 对 象 输入 的 事件 ， 考 虑 接收 输入 事件 的 边 
界 对 象 和 参与 共同 处 理事 件 的 后 续 对 象 ( 实体 对 象 或 控制 对 象 ) 之 问 的 通信 。 画 一 张 通信 
图 或 者 是 顺序 图 来 展示 参与 用 例 的 对 象 以 及 它们 之 间 传 递 消息 的 序列 。 这 个 序列 通常 由 一 
个 来 自 参 与 者 ( 外 部 对 象 ) 的 外 部 输入 开始 ， 紧 着 跟 的 是 参与 软件 对 和 象 之 间 的 内 部 消息 序 


列 ， 最 终 到 一 个 参与 者 〈 外 部 对 象 ) 的 外 部 输出 。 对 于 每 一 个 随后 的 参与 者 和 系统 之 间 的 
交互 ， 重 复 这 个 过 程 。 结 果 是 ， 额 外 的 对 象 可 能 被 要 求 参与 到 这 个 用 例 当 中 ， 由 此 会 需要 
指定 额外 的 消息 通信 和 消息 序列 编号 。 

4. 确定 可 蔡 换 序列 。 考 虑 其 他 不 同 的 可 替换 序列 ， 例 如 在 用 例 的 可 替换 部 分 描述 的 
错误 处 理 。 然 后 考虑 什么 对 象 需要 参与 到 执行 可 替换 序列 分 支 中 来 ， 以 及 在 这 些 对 象 之 间 
消息 通信 的 序列 。 





9.5 无 状态 动态 交互 建 模 示例 


这 里 会 展示 两 个 无 状态 动态 交互 建 模 的 例子 。 第 一 个 例子 从 “查看 警报 ”( View Alarms ) 
用 例 开始 ， 第 二 个 例子 从 “下 单 请 求 ”( Process Delivery Order) 用 例 开 始 。 


9.5.1 查看 警报 示例 


作为 一 个 无 状态 动态 交互 建 模 的 例子 ， 考 虑 从 应 急 监控 系统 案例 研究 中 的 “查看 警报 ” 
用 例 。 这 个 例子 遵循 在 9.4 节 中 描述 的 动态 建 模 四 个 步 又， 因为 这 是 一 个 简单 的 例子 ， 没 有 
备 选 的 序列 。 
1. 开发 用 例 模 型 
在 这 个 “查看 警报 ”用 例 中 ， 只 有 一 个 参与 者 ， 即 “监控 操作 员 ”( Monitoring Operator ), 
[40] 他 可 以 要 求 去 查看 警报 的 状态 ， 在 图 9-1 中 所 示 。 这 个 用 例 的 描述 可 以 简单 地 描述 如 下 : 


用 例 名 : 查看 警报 

参与 者 : 监控 操作 员 

概述 : 监控 操作 员 查 看 未 处 理 的 警报 并 且 可 以 知道 这 个 警报 被 人 触发 的 原因 。 
前 置 条 件 : 监控 操作 员 已 经 登录 系统 。 

主 序列 : 


1. 监控 操作 员 请 求 查看 未 处 理 的 警报 。 
2. 系统 显示 未 处 理 的 警报 。 对 于 每 一 个 警报 ， 系 统 显 示 这 个 警报 的 名 字 、 人 警报 
的 描述 、 警 报 的 地 址 和 警报 的 严重 级 别 〈 高 ， 中 ， 低 )。 
后 置 条 件 : 未 处 理 的 警报 被 显示 出 来 。 





2. 确定 实现 用 例 所 需 的 对 象 
因为 查看 警报 是 一 个 简单 的 用 例 ， 只 有 两 个 对 象 参 与 在 这 个 用 例 里 面 ， 如 图 9-2 所 示 。 
所 需 的 对 象 可 以 通过 仔细 地 阅读 用 例 来 确定 。 一 个 用 户 的 交互 对 象 被 称 为 “操作 员 交 互 ” 
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( Operator Interaction )， 它 用 来 接收 输入 并 且 发 送 输出 到 参与 者 ， 另 一 个 服务 对 象 被 称 为 “ 警 
报 服务 ”( Alarm Service )， 它 提供 访问 警报 库 的 访问 权限 并 响应 警报 请 求 。 

3. 确定 消息 通信 序列 

这 个 用 例 的 通信 图 描绘 了 用 户 交 互 对 象 。“ 操 作 员 交互 ”对 象 ， 向 服务 对 象 “警报 服务 ” 
发 出 一 个 请 求 。 ”警报 服务 ”响应 所 需要 的 信息 ( 见 图 9-2 )。 消 息 序列 对 应 于 用 例 中 描述 的 参 
与 者 和 系统 之 间 的 交互 序列 ， 如 下 所 述 : 


Al :“ 监 控 操 作 员 ”请 求 一 个 警报 处 理 服务 一 一 比如 ， 查 看 警报 或 者 订阅 某 一 个 特殊 
类 型 的 警报 消息 。 这 个 请 求 被 发 送 到 “操作 员 交 互 ”。 
Al.1:“ 操 作 员 交互 ”发 送 警 报请 求 给 “警报 服务 ”。 


Al.2 :“ 警 报 服 务 ”执行 请 求 一 一 例如 ， 赔 读 现 有 警报 的 列表 或 者 添加 用 户 交互 对 象 
的 名 字 到 订阅 列表 中 一 一 然后 发 送 响应 返回 给 “操作 员 交 互 ” 对 象 。 
Al.3:“ 操 作 员 交互 ”显示 响应 一 一 例如 ， 警 报信 息 一 一 给 操作 员 。 





9.5.2 下 单 请 求 示 例 


第 二 个 无 状态 动态 交互 建 模 的 例子 来 自在 线 购物 面向 服务 系统 中 。 这 个 例子 也 遵循 了 9.4 
节 中 描述 的 动态 建 模 的 四 个 步骤 。 


1. 开发 用 例 模型 
在 “下 单 请 求 ”( Make Order Request ) НИТ, КАН 
一 个 客户 参与 者 输入 订单 请 求 的 信息 ， 系 统 会 得 到 账 


户 信息 并 且 请 求 信 用 卡 授权 。 如 果 信 用 卡 授权 通过 ， Customer 
系统 会 创建 一 个 新 的 发 货 单 并 且 显示 订单 。 用 例 图 在 图 9-4 用 例 “ 下 单 请 求 ” 的 用 例 图 
图 9-4 中 描述 ， 用 例 的 描述 如 下 所 示 : 


用 例 名 : 下 单 请 求 
概述 : 客户 输入 订单 请 求 来 从 在 线 商 店 系统 中 买 东西 。 客 户 的 信用 卡 被 检查 合法 性 
以 及 是 否 有 足够 的 额度 来 支付 所 请 求 的 商品 的 价格 。 
参与 者 : 客户 
前 置 条 件 : 客户 选择 了 一 个 或 多 个 商品 。 
主 序列 : 
1. 客户 提供 了 订单 请 求 和 客户 账户 号 来 支付 订单 。 
2. 系统 获得 客户 的 账户 信息 ， 包 括 客户 的 信用 卡 详细 信息 。 
з. 系统 检查 客户 的 信用 卡 内 的 额度 是 否 足以 购买 所 选 商 品 ， 如 果 检 查 通过 ， 将 
会 创建 一 个 信用 卡 购 买 授权 号 。 
4. 系统 创建 一 个 发 货 单 ， 包 括 了 订单 的 详细 信息 、 客 户 号 以 及 信用 卡 授权 号 。 
5. 系统 确认 接受 这 个 购买 并 且 向 客户 显示 订单 的 信息 。 
6. 系统 向 客户 发 送 电 子 邮 件 确 认 信 。 
可 替换 序列 : 
第 二 步 : 如 果 客 户 没有 账户 ， 系 统 会 提示 客户 提供 信息 来 创建 一 个 新 的 账户 。 客 户 
可 以 输入 他 的 信息 或 者 取消 该 订单 。 
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第 三 步 : 如 果 对 客户 信用 卡 的 授权 失败 (例如 非法 状态 的 信用 卡 或 者 是 客户 信用 卡 
账户 的 额度 不 足 )， 系 统 会 提示 客户 输入 一 个 不 同 的 信用 卡号 。 客 户 可 以 输入 一 个 不 同 的 


信用 卡号 或 者 是 取消 这 个 订单。 
后 置 条 件 : 系统 为 客户 创建 一 个 发 货 单 。 





2. 确定 实现 用 例 所 需 的 对 象 

如 前 所 述 ， 实 现 用 例 所 需 的 对 象 可 以 通过 仔细 阅读 用 例 来 确定 ， 以 粗 体 显示 。 当 给 定 客 
户 参 与 者 后 ， 需 要 一 个 用 户 交 互 对 象 “客户 交互 "。 服 务 对象 需 要 四 个 服务 来 实现 这 个 用 例 : 
“客户 账户 服务 ”,“ 信 用 卡 服 务 ",“ 发 货 单 服务 ”和 “电子 邮件 服务 "。 同 时 还 需要 一 个 协调 
者 对 象 “ 客 户 协 调 者 ”， 来 协调 “客户 交互 ”和 其 他 四 个 服务 对 和 象 。 

3. 确定 消息 通信 序列 

下 一 个 要 考虑 的 是 这 些 对 象 之 间 的 交互 序列 ， 如 图 9-5 所 示 。 这 些 对 象 之 间 的 交互 序列 
需要 反映 参与 者 和 系统 之 间 的 交互 序列 ， 就 像 用 例 中 描述 的 那样 。 用 例 描 述 ( 第 一 步 ) 表示 
了 客户 请 求 创建 一 个 订单 。 要 实现 这 一 用 例 步骤 ,“ 客 户 交 互 ”发 出 一 个 订单 请 求 给 “客户 
协调 者 ”( 通信 图 中 的 消息 M1 和 M2 )。 在 第 二 步 的 用 例 中 ， 系 统 获得 了 账户 的 信息 。 要 实 
现 这 个 用 例 步 又,“ 客 户 协调 者 ”需要 从 “客户 账户 服务 ”那里 请 求 账户 信息 (通信 图 中 的 消 
息 M3 和 М4 )。 在 用 例 的 第 三 步 ， 系 统 检查 客户 的 信用 卡 。 要 实现 这 个 用 例 步骤 ,“ 客 户 协调 
者 ”需要 从 “信用 卡 服务 ”那里 请 求 信 用 卡 授 权 信息 (通信 图 的 消息 Ms )。 在 用 例 的 主 序列 
里 ， 信 用 卡 授权 请 求 被 批准 ， 就 像 通信 图 中 消息 M6 展示 的 那样 。 在 用 例 的 第 四 步 ， 系 统 创 
建 了 一 个 发 货 单 。 要 实现 用 例 的 这 个 步骤 ,“ 客 户 协调 者 ”需要 在 “发 货 单 服务 ”中 储存 订单 
(通信 图 上 的 消息 М7 和 М8 )。 接 下 来 在 用 例 中 ， 系 统 确 认 给 用 户 的 订单 (消息 M9 和 MI10 )， 
并 且 通 过 电子 邮件 服务 发 送 一 封 确认 邮件 (并 发 消息 M9a )。 

MI: Order F Request 


= 
M10: Customer Output 
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M2: Order Request у 1 M9: Order Confirmation 
«coordinatom 
aCustomerCoordinator 


М7: Store Order у 


M3: Account Request 














MS: Authorize Credit Card Request 
<= 








«service» 
: CreditCard 
Service 


— 






— 
Мб: Credit Card Approved 


= 
М4: Account Info 


«service» 
: CustomerAccountService 


M9a: Send Order 
Confirmation Email 


“З 
«service» 
: EmailService 






1 М8: Order Confirmation 


# 9-5 用 例 “ 下 单 请 求 ” 的 通信 图 : 主 序列 
“下 单 请 求 ” 用 例 的 通信 图 在 图 9-5 中 描述 。 消 息 描述 如 下 : 





М1: 客户 向 “客户 交互 ”发 送 了 订单 请 求 。 


M2:“ 客 户 交互 ”向 “客户 协调 者 ”发 送 订单 请 求 。 
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M3，M4 :“ 客 户 协调 者 ”向 “客户 账户 服务 ”发 送 账 户 请 求 并 且 接 收 账户 信息 ， 包 
括 客户 信用 卡 的 详细 信息 。 

MS:“ 客 户 协调 者 ”向 “信用 卡 服务 ”发 送 了 客户 的 信用 卡 信息 。 

M6:“ 信 用 卡 服 务 ” 向 “客户 协调 者 ”发 送 了 一 个 信用 卡 批准 。 


M7，M8:“ 客 户 协调 者 ”向 “发 货 单 服务 ”发 送 了 订单 请 求 。 

M9，M9a:“ 客 户 协调 者 ”向 “客户 交互 ”发 送 了 订单 确认 信息 并 且 通 过 “电子 邮件 
服务 ”向 客户 发 送 了 订单 确认 邮件 。 

M10:“ 客 户 交互 ”向 客户 输出 订单 确认 。 


对 于 相同 场景 的 顺序 图 ， 也 就 是 “下 单 请 求 ”用 例 的 主 序列 在 图 9-6 中 描绘 ， 展 示 了 页 
面 中 从 上 到 下 的 主 序列 。 

4. 确定 可 替换 序列 

对 于 这 个 用 例 的 可 替换 场景 是 : 客户 没有 账户 ， 这 种 情况 下 将 会 创建 一 个 新 账户 ; 或 者 
是 信用 卡 授权 没有 得 到 批准 ， 这 种 情况 下 客户 可 以 选择 另 一 张 信 用 卡 来 支付 。 我 们 对 这 两 种 
可 替换 场景 进行 分 析 。 

新 账户 的 可 替换 场景 在 图 9-7 中 描绘 。 这 种 场景 是 从 主场 景 第 M4A 步 又 中 分 支出 来 
的 。 对 于 第 M3 步 的 账户 请 求 的 可 替换 回复 是 M4A[ 无 账户 ] : 账户 不 存在 。M4A 是 一 个 
有 条 件 的 消息 ， 只 有 当 对 于 [无 账户 ] 的 这 种 可 蔡 换 情况 判断 为 真 的 时 候 才 会 触发 这 个 消 
息 。 对 于 这 个 可 替换 场景 的 消息 序列 是 通过 M4A.8 来 展示 的 ， 如 下 所 述 : 


M4A:“ 客 户 账户 服务 ”向 “客户 协调 者 ”回复 了 消息 ， 显 示 这 个 客户 没有 账户 。 

МААЛ, МАА2 :“ 客 户 协调 者 ”通过 “客户 交互 ”向 客户 发 送 了 一 个 要 求 创建 新 账 
户 的 请 求 。 

M4A.3, M4A.4: 客户 向 “客户 交互 ”输入 账户 信息 ， 并 向 “客户 协调 者 ”传递 了 
消息 。 

M4A.5:“ 客 户 协 调 者 ”向 “客户 账户 服务 ”请 求 创建 一 个 新 的 账户 。 

M4A.6，M4A.7，IM4A.8 :“ 客 户 账户 服务 ”确认 新 账户 ， 然 后 通过 “客户 协调 者 ” 
和 “客户 交互 ”回复 给 客户 。 


信用 卡 被 拒绝 的 可 替换 场景 在 图 9-8 中 描绘 。 这 种 场景 是 从 主场 景 中 的 第 M6A 步骤 中 分 
支出 来 的 。 对 于 第 MS 步 中 的 信用 卡 授权 请 求 的 可 替换 回复 是 M6A[ 拒绝 ] : 信用 卡 被 拒绝 。 
МА 是 一 个 有 条 件 的 消息 ， 只 有 在 布尔 型 (Boolean ) 条 件 [ 拒绝 ] 为 真 时 才 会 被 发 送 。 该 可 
替换 场景 的 消息 序列 从 M6A 到 M6A.2， 如 下 所 述 : 


M6A:“ 信 用 卡 服务 ”向 “客户 协调 者 ”发 送信 息 ， 告 知 其 拒绝 了 信用 卡 授权 。 
M6A.1:“ 客 户 协调 者 ”通知 “客户 交互 "， 信 用 卡 被 拒绝 。 


M6A.2 :“ 客 户 交互 ”通知 客户 ， 信 用 卡 被 拒绝 ， 并 提示 其 重新 输入 一 张 不 同 的 信 
用 卡号 。 
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图 9-6 的 顺序 图 和 图 9-5、 图 9-7 МИ 9-8 的 通信 图 都 描绘 的 是 “下 单 请 求 ”用 例 的 单 
独 场景 ( 主场 景 或 可 替换 场景 )。 我们 有 可 能 把 几 个 场景 合并 到 一 个 通用 的 交互 图 。 图 9-9 
就 是 在 图 9-5 ( EPPS). B 9-7 ЖИ 9-8 ( 可 替换 序列 ) 三 个 场景 的 基础 上 描绘 的 一 张 更 加 通 
用 的 通信 图 。 注 意 对 于 不 同 场景 所 使 用 的 可 替换 消息 序列 编号 。 账 户 请 求 消息 МЗ 的 可 替换 
序列 由 M4[ 账户 已 存在 ] 和 M4A[ 无 账户 ] 这 两 个 可 替换 序列 给 出 。 信 用 卡 授 权 请 求 消息 М5 
的 可 替换 序列 由 M6[ 批准 ] 和 M6A[ 拒绝 ] 这 两 个 可 替换 序列 给 出 。 


«user interaction» «coordinator» «service» 
: Customer aCustomer : Customer 
Interaction Coordinator AccountService 
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图 9-7 用 例 “ 下 单 请 求 ”的 顺序 图 : 创建 新 账户 的 可 替换 序列 


МТ: Order Request 
一 > 
<= 
M6A.2: Customer Output 


aCustomer 






«user interaction» 
: Customer 
Interaction 









M2: Order Request. | | { MGA.1: Credit Card Denied 










M3: Account Request 
一 > 











«service» 
: CreditCard 
Service 


М5: Authorize Credit Card Request 
< 







«coordinator» «service» 
aCustomerCoordinator : CustomerAccountService 


图 9-8 用 例 “ 下 单 请 求 ” 的 通信 图 : 信用 卡 被 拒绝 的 可 替换 序列 


“下 单 请 求 ” 用 例 的 三 个 相同 的 场景 在 图 9-10 的 通用 顺序 图 上 描述 。 该 顺序 图 描绘 了 在 
创建 账户 的 过 程 中 和 请 求 信用 卡 授权 时 的 两 个 可 替换 序列 。 第 一 个 Ан 段 描 绘 了 两 个 可 替换 
序列 [账户 已 存在 ] 和 [无 账户 ]。 第 二 个 Alt 段 描绘 了 两 个 可 蔡 换 序列 [批准 ] 和 [拒绝 ]。 
在 每 一 个 用 例 中 ， 用 短 划 线 在 可 替换 序列 之 间 分 隔 。 在 顺序 图 上 ， 消 息 序 列 编号 是 可 选 的 ， 
但 是 ， 和 通信 图 上 对 应 的 部 分 则 要 显 式 地 描绘 出 来 。 
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9.6 总 结 


本 章 讨 论 了 动态 建 模 ， 即 确定 用 例 中 的 参与 对 象 以 及 这 些 对 象 之 间 的 交互 序列 的 过 程 。 
本 章 首先 描述 了 通信 图 和 顺序 图 ， 解释 了 它们 如 何 用 于 动态 建 模 ， 然 后 描述 了 动态 交互 建 模 
方法 在 确定 对 象 间 互 相 协 作 的 细节 。 状 态 相关 的 动态 交互 建 模 包括 了 一 个 由 状态 图 控制 的 状 
态 相 关 的 通信 (FESS 11 章 中 描述 )， 而 无 状态 的 动态 交互 建 模 则 没有 这 一 特点 。 

在 设计 过 程 中 ， 对 应 于 每 一 个 用 例 的 通信 图 都 被 合成 为 一 张 集成 通信 图 ， 它 代表 了 开发 
软件 系统 架构 的 第 一 步 ， 这 将 在 第 13 章 中 描述 。 在 分 析 的 过 程 中 ， 所 有 的 消息 交互 都 被 描绘 
成 简单 消息 ， 因 为 关于 消息 的 特性 还 没有 被 确定 。 在 设计 的 过 程 中 ， 消 息 接口 将 在 第 12 章 和 
第 13 章 中 加 以 定义 和 描述 。 


练习 


选择 题 ( 每 道 题 选择 一 个 答案 ) 

1. 交互 图 是 描述 什么 的 ? 

(а) 在 一 个 控制 对 象 里 的 状态 和 转换 (b ) 类 和 类 间 的 关系 

(с) 软件 对 象 和 它们 之 间 交 互 的 序列 (а) 外 部 对 象 和 系统 之 间 的 通信 
2. 在 交互 图 上 怎样 描绘 一 个 参与 者 ? 

(а) 参与 者 和 交互 图 之 间 有 一 个 关联 

(b ) 一 个 参与 者 可 以 向 一 个 边界 对 象 提 供 输 入 或 从 其 接收 输出 

(с) 一 个 参与 者 可 以 向 一 个 边界 类 提供 输入 或 从 其 接收 输出 

(4) 一 个 参与 者 的 实例 可 以 向 一 个 边界 对 象 提供 输入 或 从 其 接收 输出 

3. 顺序 图 描绘 了 什么 ? 


(а) 外 部 对 象 之 间 互 相通 信 的 序列 (b) 类 和 类 间 的 关系 

Co) 软件 对 象 和 它们 之 间 交 互 的 序列 (4) 外 部 对 象 和 系统 的 通信 
4. 通信 图 描绘 了 什么 ? 

Ca) 外 部 对 象 之 间 互 相通 信 的 序列 (b) 类 和 类 间 的 关系 

(с) 软件 对 象 和 它们 之 间 交 互 的 序列 (4) 外 部 对 象 和 系统 的 通信 


5. 下 列 哪 一 项 是 交互 图 的 实例 形式 ? 

(а) 描述 若干 个 相互 交互 的 对 象 实例 

(b) 描述 一 个 可 能 的 对 象 实例 间 的 交互 序列 

(с) 描述 所 有 可 能 的 对 象 实例 间 的 交互 

(а) 描述 所 有 对 象 实例 和 它们 之 间 的 链接 

6. 下 列 哪 一 项 是 交互 图 的 通用 形式 ? 

(а) 描述 若干 个 相互 交互 的 对 象 (b) 描述 一 个 对 象 间 可 能 的 交互 序列 
(с) 描述 所 有 可 能 的 对 象 间 的 交互 (d) 描述 所 有 对 象 类 和 它们 之 间 的 链接 
7. 在 动态 交互 建 模 的 过 程 中 ， 用 例 被 实现 为 以 下 哪 一 项 ? 

(а) 确定 参与 每 一 个 用 例 的 对 象 和 对 象 之 间 的 交互 序列 

(b) 确定 外 部 对 象 和 它们 向 每 一 个 用 例 提供 输入 和 从 其 接收 输出 的 序列 

(с) 确定 用 例 间 交 互 的 序列 
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(а) 确定 一 个 用 例 是 如 何 通过 内 部 状态 和 状态 间 的 转换 来 描述 的 
8. 下 列 哪 一 个 交互 可 能 在 交互 图 中 发 生 ? 

(а) 外 部 用 户 向 用 户 接口 对 象 发 送 一 个 消息 

(b) 外 部 用 户 向 实体 对 象 发 送 一 个 消息 

(с) 外 部 用 户 向 输入 /输出 对 象 发 送 一 个 消息 

(а) 外 部 用 户 向 打印 机 对 象 发 送 一 个 消息 
9. 下 列 哪 一 个 交互 是 不 会 在 交互 图 中 发 生 的 ? 

(а) 用 户 交 互 对 象 向 实体 对 象 发 送 一 个 消息 

(b) 输入 对 象 向 状态 相关 的 控制 对 象 发 送 一 个 消息 

(с) 输入 对 象 向 打印 机 对 象 发 送 一 个 消息 

(а) 用 户 交互 对 象 向 代理 对 象 发 送 一 个 消息 
10. 哪 类 对 象 是 第 一 个 从 外 部 对 象 接 收 输入 的 对 象 ? 

(a) 用 户 交 互 对象 (b ) 代理 对 象 
(с) 实体 对 象 (а) 边界 对 象 
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有 限 状态 机 





有 限 状 态 机 用 来 对 系统 或 对 象 的 控制 和 顺序 视图 进行 建 模 。 很 多 系统 例如 实时 系统 ) 
与 状态 高 度 相 关 。 也 就 是 说 ， 它 们 的 行为 不 仅 取决 于 输入 ， 也 取决 于 系统 之 前 所 发 生 的 事件 。 
定义 有 限 状 态 机 的 表示 法 有 状态 转 转 换 图 、 状 态 图 和 状态 转换 表 。 在 与 状态 高 度 相 关 的 系统 
中 ， 这 些 表示 法 非常 有 助 于 提供 一 种 视角 来 帮助 理解 系统 的 复杂 性 。 

在 UML 表示 法 中 ， 状 态 转换 图 也 被 称 为 状态 机 图 。UML 状态 机 图 基于 Harel 的 状态 图 
表示 法 (Harel 1988 ; Harel and Politi 1998 )。 在 本 书 中 ， 术 语 状 态 图 和 状态 机 图 可 交替 使 用 。 
我 们 将 传统 的 不 分 层 的 状态 转换 图 称 为 扁平 化 状态 图 (flat statechart )， 同 时 使 用 术语 层次 化 
RAA (hierarchical statechart ) 表示 层次 化 状态 分 解 的 概念 。 状 态 图 表示 法 的 概述 在 第 2 章 
BAW (2.6 47 )。 

本 章 首先 阐述 扁平 化 状态 图 的 特性 ， 然 后 描述 层次 化 状态 图 。 为 了 展现 层次 化 状态 图 带 
来 的 好 处 ， 本 章 从 扁平 化 状态 图 的 最 简单 形式 出 发 ， 展 示 其 进行 了 怎样 的 改进 后 达到 层次 化 
状态 图 的 完整 的 建 模 能 力 。 来 源 于 两 个 案例 研究 的 多 个 示例 贯穿 本 章 ， 这 两 个 案例 分 别 是 自 
动 柜员 机 有 限 状 态 机 和 微波 炉 有 限 状 态 机 。 

10.1 节 描 述 有 限 状态 机 中 的 事件 和 状态 。10.2 节 介绍 状态 图 的 示例 。10.3 节 描 述 事 件 和 
警戒 条 件 。10.4 节 描 述 状 态 图 的 动作 。10.5 节 描 述 层次 化 状态 图 。10.6 节 为 开发 状态 图 提供 
指导 。10.7 节 描 述 从 用 例 开发 状态 图 的 过 程 。 


10.1 有 限 状 态 机 和 状态 转换 


有 限 状 态 机 ( 也 称 为 状态 机 ) 是 包含 有 限 个 状态 的 概念 化 机 器 。 状 态 机 在 某 一 时 刻 只 能 有 
一 个 状态 。 状 态 转换 是 由 输入 事件 引起 的 状态 的 改变 。 为 了 对 一 个 输入 事件 进行 响应 ， 有 限 状 
态 机 会 转换 到 一 个 不 同 的 状态 。 另 外 一 种 情况 是 ， 该 事件 可 能 没有 作用 ， 有 限 状 态 机 仍然 维持 
在 同一 个 状态 。 下 一 个 状态 依赖 于 当前 状态 和 输入 事件 。 有 时 ， 状 态 转 换 会 导致 输出 动作 。 

尽管 一 个 完整 的 系统 可 以 通过 有 限 状 态 机 来 建 模 ， 然 而 在 面向 对 象 的 分 析 和 设计 中 ， 一 
个 有 限 状 态 机 被 封装 在 一 个 对 象 内 部 。 换 句 话说， 这 个 对 象 是 与 状态 相关 的 ， 并 总 是 处 于 有 
限 状态 机 中 的 某 一 状态 。 对 象 的 有 限 状 态 机 通过 状态 图 来 描绘 。 在 面向 对 象 的 模型 中 ， 一 个 
系统 的 状态 相关 的 视图 通过 一 个 或 多 个 状态 机 定义 ， 每 一 个 有 限 状 态 机 被 封装 在 它 自己 的 对 
象 里 。 在 给 出 状态 图 的 示例 前 ， 本 节 首 先 描述 事件 和 状态 的 基本 概念 。 


10.1.1 事件 


事件 是 在 某 一 个 时 间 点 发 生 的 事情 ， 事 件 也 被 称 为 离散 事件 、 离 散 信号 或 激励 。 一 个 事 
件 具 有 原子 性 〈 不 可 中 断 ) 且 在 概念 上 无 持续 。“ 卡 片 已 经 插入 ”( Сага Inserted), “Pin 码 已 
输入 ”( Pin Entered )、“ 门 已 开 ”( Door Opened ) 等 都 是 事件 。 

事件 会 相互 依赖 。 例 如 ， 在 一 个 给 定 的 事件 序列 中 ， 事 件 “ 卡 片 已 插入 ”总 是 在 事件 
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“Pin 码 已 输入 ”之 前 发 生 。 在 这 种 情况 下 ， 第 一 个 事件 (“卡片 已 插入 ”) 会 使 状态 转换 为 
“等 待 PIN 码 ”( Waiting for PIN) 的 状态 ， 而 下 一 个 事件 (“Pin 码 已 输入 ”) 会 将 该 状态 转换 
为 其 他 状态 。 这 两 个 事件 的 先后 顺序 通过 连接 它们 的 状态 显示 出 来 ， 如 图 10-1 所 示 。 

一 个 事件 可 以 源 自 外 部 ,例如 “卡片 已 插入 ”( 是 
用 户 将 卡片 插入 到 读 卡 器 的 结果 )， 也 可 以 通过 系统 内 
部 生成 ， 例 如 “有 效 PIN 码 ”( Valid PIN )。 


10.1.2 ”状态 














Waiting for 
Customer Choice 


Card Inserted 
状态 表示 一 种 可 识别 的 、 存 在 于 一 段 时 间 间 隔 内 的 
情况 。 与 在 某 一 时 间 点 发 生 的 事件 不 同 ， 一 个 有 限 状 态 
机 在 一 段 时 间 内 总 处 于 一 个 给 定 的 状态 。 有 限 状 态 机 中 вм entered 
事件 的 到 达 经 常 导致 状态 机 从 一 个 状态 转换 为 另 一 个 状 
态 。 另 外 一 种 情况 是 ， 事件 有 可 能 不 产生 任何 效果 ， 此 
时 有 限 状 态 机 仍然 处 于 相同 的 状态 。 理 论 上 来 说 ， 状 态 
转换 不 需要 时 间 。 而 实际 上 ， 和 状态 内 部 持续 的 时 间 相 
比 ， 状 态 转换 发 生 的 时 间 可 以 忽略 。 кн 
有 些 状态 表示 状态 机 正在 等 待 外 部 的 事件 。 例 
如 ， 状 态 “ 等 待 PIN 码 ”是 指 状态 机 正在 等 待 客户 输 
人 PIN 码 ， 如 图 10-1 所 示 。 其 他 状态 表示 状态 机 正在 
等 待 系统 其 他 部 分 的 响应 。 例 如 ， 状 态 “ 验 证 PIN 码 ” 图 10-1 状态 图 主 顺 序 示例 
( Validating PIN ) 表示 系统 正在 检查 客户 PIN 码 的 状态 。 下 一 个 事件 将 指示 该 验证 是 否 成 功 。 
状态 机 的 初始 状态 是 指 状态 机 被 激活 时 进入 的 状态 。 例 如 ，ATM 状态 图 的 初始 状态 是 
«әз Ы” (Idle) 状态 ， 如 图 10-1 所 示 ， 在 UML 中 是 由 源 自 于 黑色 小 圆圈 的 弧 线 来 识别 的 。 


10.2 ”状态 图 示例 
扁平 化 状态 图 的 使 用 是 通过 两 个 示例 来 说 明 的 ， 这 两 个 示例 是 АТМ 状态 图 和 微波 炉 状态 图 。 
10.2.1 ATM 状态 图 示例 


图 10-1 展示 了 一 个 自动 柜员 机 的 部 分 状态 图 。 ATM 状态 图 的 初始 状态 是 “空闲 ”( Idle )。 
考虑 如 下 场景 : 客户 将 卡片 插入 ATM 机 ,输入 PIN 码 ， 然 后 选择 现金 取款 。 当 事件 “卡片 
已 插入 ”( Card Inserted ) 到 达 时 ，ATM 状态 机 从 “ 空 辣 ”(Idle ) 状态 转换 为 “等 待 PIN 码 ” 
( Waiting for PIN) 状态 ， 在 该 状态 下 ATM 等 待 客户 输入 PIN 码 。 当 事件 “PIN 码 已 输入 ” 
(PIN Entered ) 发 生 时 ，ATM 转换 为 “验证 PIN 码 ”( Validating PIN ) 状态 。 在 该 状态 下 ,“ 银 
行 系统 ”验证 客户 输入 的 PIN 码 是 否 和 该 卡片 存储 的 PIN 码 匹 配 ， 并 验证 该 卡 是 否 已 经 挂失 
或 被 盗 。 假 如 该 卡 及 其 PIN 码 验 证 成 功 (事件 :“ 有 效 PIN 码 ”，Valid РІМ), АТМ 会 转换 为 
“等 待 客户 选择 ”( Waiting for Customer Choice ) 的 状态 。 

根据 不 同 的 事件 ， 一 个 状态 可 能 会 转换 为 多 个 状态 。 考 虑 从 验证 PIN 码 状 态 转换 至 其 他 
状态 的 情况 。 图 10-2 展示 了 从 “验证 PIN 码 ” 状 态 转 换 至 的 三 种 可 能 的 状态 。 如 果 两 个 PIN 
码 匹 配 成 功 ， 则 ATM 从 “有 效 PIN 码 ”( Valid PIN ) 状态 换 为 “等 待 客户 选择 ”( Waiting for 
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Customer Choice ) 状态 。 如 果 两 个 PIN 码 不 匹配 ， 则 ATM 触发 “无 效 PIN #3” (Invalid PIN ) 
事件 ， 并 重新 进入 “等 待 PIN 码 ”( Waiting for PIN ) 状态 ， 同 时 提示 客户 输入 不 同 的 РІМ 码 。 
如 果 客 户 三 次 输入 的 PIN 码 都 无 效 ， 那 么 АТМ 会 触发 “第 三 次 无 效 PIN 码 ”(Third Invalid 
PIN ) 的 事件 并 进入 “没收 卡片 ”( Confiscating ) 状态 ， 这 将 导致 卡片 被 厨 。 如 果 卡 片 在 验证 
时 已 经 挂失 或 被 盗 ， 或 卡片 已 过 期 ， 则 АТМ 也 会 转换 到 该 状态 。 






Card Inserted 










Waiting for PIN 
PIN Entered м Invalid PIN 
Third Invalid PIN, 
Card Stolen, Card Expired 
Validating PIN Confiscating 


Valid PIN 


Waiting for 
Customer Choice 


图 10-2 ”状态 图 中 可 替换 事件 示例 


在 某 些 情况 下 ， 同 一 个 事件 可 能 发 生 在 不 同 的 状态 下 并 具有 相同 的 作用 ， 如 图 10-3 所 示 
的 示例 。 客 户 可 能 决定 在 “等 待 PIN 码 ”( Waiting for РІМ), “验证 PIN 码 ”( Validating PIN ) 或 
“等 待 客户 选择 ”( Waiting for Customer Choice ) 这 三 个 状态 的 任意 一 个 中 选择 “取消 ”( Cancel ), 
这 将 导致 状态 图 进入 “ 退 卡 ”( Ejecting ) 状态 ， 该 状态 表示 退出 ATM 卡 ， 交 易 也 随 之 中 止 。 






Card Inserted 


Waiting for PIN 









PIN Entered 5 Invalid PIN 
Third Invalid PIN, 
Card Stolen, Card Expired Ejecting 
Validating PIN Confiscating 








Valid PIN 


Waiting for 
Customer Choice 


Cancel 


图 10-3 在 不 同 状态 中 发 生 相 同事 件 示例 
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同一 个 事件 也 可 能 发 生 在 不 同 的 状态 下 并 具有 不 同 的 作用 。 例 如 ， 如 果 在 “空闲 ”( Idle ) 
状态 时 发 生 了 “PIN 码 已 输入 ”( PIN Entered) 的 事件 ， 那 么 该 事件 就 会 被 忽略 。 

接 下 来 考虑 如 图 10-4 所 示 的 场景 : РІМ 码 验 证 成 功 后 ， 客 户 选择 从 АТМ 中 取款 。 当 处 
于 “等 待 客户 选择 ”( Waiting for Customer Choice ) 状态 时 ， 客 户 做 出 选择 ， 例 如 选择 取款 。 
状态 图 接 下 来 接收 事件 “选择 取款 ”( Withdrawal Selected )， 进 入 “处 理 取款 ”( Processing 
Withdrawal) 的 状态 。 如 果 取 款 通过 ， 状 态 图 进入 “出 钞 ”( Dispensing ) 状态 ， 此 时 钞票 被 
吐出 。 当 发 生 “ 现 金 已 取出 ”( Cash Dispensed ) 的 事件 时 ，ATM 转换 为 “打印 ”( Printing ) 
状态 并 打印 赁 条 。 当 和 赁 条 打印 完成 后 ，ATM 进入 “ 退 卡 ”(Ejecting ) 状态 。 事 件 “ 卡 片 已 退 
出 ”(Card Ejected ) 发 生 后 ， 卡 片 被 退出 ，ATM 进入 “终止 ”(Terminating ) 状态 。 








After (Elapsed Time) 


Card Ejected 


Ejecting 


Receipt Printed 


Card Inserted 


Waiting for PIN 


PIN Entered 

















Validating PIN 


Valid PIN 







Waiting for 
Customer Choice 


Cash Dispensed 


Processing | | 


Al 10-4 完整 的 ATM 场景 示例 : 现金 取款 场景 


从 “终止 ”( Terminating ) 状态 开始 ， 计 时 器 事件 促使 状态 转 回 “空闲 ”( Idle ) 状态 。 计 
时 器 事件 描述 为 “已 过 时 间 ”( After (Elapsed Time ) )， 而 “已 过 时 间 ” 是 处 于 “终止 ”状态 
的 时 间 ( 从 进入 该 状态 到 因为 计时 器 事件 而 退出 该 状态 的 时 间 )。 


10.2.2 ”微波炉 状态 图 示例 


图 10-5 展示 了 一 个 简化 的 “微波 炉 控 制 ” 状 态 图 ， 它 是 状态 图 的 第 二 个 示例 ， 该 状态 图 
显示 了 做 饭 的 不 同 状态 。 初 始 状态 是 “ 门 关 闭 ”( Door Shut )。 考 虑 从 用 户 打开 门 开始 的 场景 ， 
结果 是 状态 图 转换 为 “ 门 打开 ”( Door Open) 的 状态 。 用 户 接 下 来 将 食物 放 到 炉子 里 ， 使 状 
态 图 转换 为 “ 门 打开 并 放 有 食物 ”( Door Open with Item) 的 状态 。 当 用 户 关 上 门 时 ， 状 态 转 
换 为 “ 门 关 闭 并 放 有 食物 ”( Door Shut with Item) {НР А RER, ЖАНА “ИЕ 





Withdrawal Selected Withdrawal Approved 
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ЖАКЕ” (Ready to Cook )。 接 下 来 用 户 按 下 开始 按钮 ， 状 态 图 转换 为 “正在 豪 饪 ”( Cooking )。 
当 到 达 设 定时 间 时 ， 状 态 图 离开 “正在 豪 饪 ”( Cooking ) 状态 ,重新 进入 “ 门 关闭 并 放 有 食 
物 ”( Door Shut with Item) 状态 。 如 果 在 亮 饪 时 门 被 打开 ， 状 态 图 将 进入 “ 门 打 开 并 放 有 食 


物 ”( Door Open with Item ) 状态 。 





Door Opened 


ltem Placed 








Door Opened 





Door Closed 





Timer Expired 





Cooking 











Door Open 
With Item 


Door Closed Door Open 


Item Removed 











Door Opened 


Door Shut 
With Item 


Cooking Time Entered 





Cooking Time Entered 


图 10-5 简化 的 微波 炉 控 制 的 状态 图 


10.3 ”事件 和 警戒 条 件 


通过 使 用 警戒 条 件 ， 可 以 使 状态 转换 具有 Item Placed 
条 件 性 。 这 可 以 通过 在 定义 状态 转换 时 将 事件 
和 和 警戒 条 件 结合 起 来 而 实现 。 表 示 法 为 “事件 
[ %4 ]” (Event [Condition] )。 条 件 是 某 一 段 时 
间 内 值 为 True 或 False 的 布尔 表达 式 。 假 如 方 7997 Closed Zero Тт] 
括号 内 警戒 条 件 的 值 为 真 ， 并 且 事 件 发 生 ， 就 
会 导致 状态 发 生 转 换 。 另 外 ， 条 件 是 可 选 的 。 


转换 ， 但 需要 记 住 它 产 生 的 影响 ， 因 为 它 会 影 

响 随后 的 状态 转换 。 若 事件 已 经 发 生 ， 则 可 以 

将 该 情况 保存 为 一 个 条 件 ， 在 之 后 进行 检验 。 
图 10-6 中 的 警戒 条 件 示 例 是 微波 炉 状 态 


Doo 
wi 


г Open 
ith Item 


Door Shut 
with Item 


某 些 情况 下 ， 一 个 事件 不 会 立即 导致 状态 Сото Time Entered 


Ready To Cook 








ltem Removed 


Door Closed [Time Remaining] 





Door Opened 






Door Opened 









图 中 的 “剩余 时 间 为 0”( Zero Time) Al “R Cooking Time Entered 
余 时 间 不 为 0”( Time Remaining )。“ 门 打开 并 图 10-6 事件 和 条 件 示 例 
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放 有 食物 ”( Door Open with Item ) 状态 有 两 个 转换 事件 :“ 门 被 关闭 [ 剩余 时 间 为 0]”( Door 
Closed [Zero Time] ) 和 “ 门 被 关闭 [剩余 时 间 不 为 0]”( Door Closed [Time Remaining] )。 因 
此 ， 该 状态 转换 取决 于 用 户 之 前 是 否 输入 了 加 热 时 间 ( 或 之 前 的 计时 器 是 否 已 到 时 )。 如 果 条 
件 “ 剩 余 时 间 为 0” 为 真 ， 则 状态 图 转换 为 “ 门 关闭 并 放 有 食物 ”( Door Shut with Item) 状 
态 ， 等 待 用 户 输入 时 间 。 如 果 条 件 “ 剩 余 时 间 不 为 0” 为 真 ， 则 状态 图 转换 为 “准备 毫 饪 ” 
( Ready to Cook ) 状态 。 


10.4 动作 


动作 是 与 状态 转换 相关 的 可 选 的 输出 。 动 作 执行 了 计算 ， 作 为 状态 转换 的 结果 。 事 件 导 
致 状态 的 转换 ， 而 动作 是 状态 转换 所 产生 的 效果 。 动 作 在 状态 转换 时 被 触发 。 它 执行 ， 随 后 
自行 中 止 。 动 作 在 状态 转换 时 立即 执行 ， 因此 理论 上 说 一 个 动作 的 持续 时 间 为 零 。 实 际 上 ， 
与 状态 持续 的 时 间 相 比 ， 动 作 持 续 的 时 间 很 短 。 

如 10.4.1 节 所 述 ， 动 作 在 状态 转换 上 描绘 。 当 与 状态 关联 而 不 是 与 进入 或 退出 状态 的 转 
换 关联 时 ， 特 定 动作 能 被 更 加 准确 地 描绘 ,它们 是 进入 动作 和 退出 动作 。 如 10.4.2 节 所 述 ， 
当 进 入 状态 时 ， 进 入 动作 被 触发 ; 当 离 开 该 状态 时 ， 退 出 动作 被 触发 ， 如 10.4.3 节 所 述 。 


10.4.1 状态 转换 中 的 动作 


转换 动作 是 指 当 从 某 一 状态 转换 为 另 一 状态 时 产生 的 动作 ， 该 动作 也 可 能 发 生 在 状态 
转换 至 自身 状态 时 。 为 了 描述 状态 图 中 的 动作 ， 将 状态 转换 表示 为 :“ 事 件 /动作 ”( Event/ 
Action ) 或 “事件 [条件 ]/ 动作 ”( Event [Condition]/Action )。 










考虑 АТМ 状态 图 中 的 动作 : 当 事 件 “卡片 已 插入 ”发 生 时 ，ATM 从 状态 “空闲 ”转换 
为 状态 “等 待 PIN 码 ”( 图 10-2 )。 发 生 在 该 状态 转 
换 中 的 动作 是 “获取 PIN 码 ”( Get PIN )。 作 为 状态 
机 的 输出 ， 该 动作 提示 客户 输入 PIN #9. И 10-7 ЈЕ 
示 了 ATM 的 部 分 状态 图 ( 原始 图 请 参看 图 10-1 )， белее! 
并 且 增 加 了 动作 。 在 “等 待 PIN 码 ” 状 态 中 ，ATM 
等 待 客户 输入 PIN 码 。 当 事件 “PIN 码 已 输入 ”到 来 
时 , ATM 转换 为 “验证 PIN 码 ” 状 态 ， 并 且 动 作 “ 验 
证 PIN 码 ”( Validate PIN ) 被 执行 。 该 状态 转换 标记 ete 
为 “PIN 码 已 输入 /验证 PIN 码 ”(PIN entered / Validate PIN 
Validate PIN )。 在 状态 “验证 PIN 码 ” 中 ， 系 统 检验 
客户 输入 的 PIN 码 和 卡片 中 存储 的 PIN 码 是 否 匹 配 ， Validating PIN 
并 检验 ATM 的 卡片 是 否 已 挂失 或 被 盗 。 如 果 卡 片 和 
PIN 码 验证 成 功 ( 发生 了 “有 效 PIN 码 ”事件 )， пар, 
ATM 转换 为 “等 待 客户 选择 ”的 状态 。 Беру Mano 
多 个 动作 可 以 和 同一 个 状态 转换 关联 ， 这 是 因 
为 动作 都 是 并 发 执行 的 ， 这 些 动 作 之 间 不 能 有 任何 на а 
的 相互 依赖 关系 。 例 如 ， 不 能 同时 发 生 两 个 并 发 的 
事件 ， 如 “计算 余额 ”( Compute Change ) 和 “显示 图 10-7 主 序列 中 动作 示例 
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RA” (Display Change )。 因 为 这 两 个 动作 之 间 有 先后 顺序 的 依赖 关系 ， 在 余额 计算 之 前 不 能 
显示 出 来 。 为 了 避 开 这 个 问题 ， 可 以 引入 中 间 状 态 “ 计 算 余 额 ”( Computing Change )。 动 作 
“计算 余额 ”在 进入 该 状态 时 执行 ， 动 作 “ 显 示人 余额 ”在 退出 该 状态 时 执行 。 

状态 图 中 可 以 存在 多 个 可 替换 的 动作 ， 如 图 10-8 所 示 。 很 多 动作 都 可 能 是 验证 PIN 码 的 
结果 。 如 果 PIN 码 有 效 ， 则 状态 机 转换 为 “等 待 客 户 选择 ”的 状态 ， 动 作 是 显示 选择 菜单 。 
如 果 PIN 码 无 效 ， 则 状态 机 回 到 “等 待 PIN 码 ” 的 状态 ， 动 作 是 提示 “无 效 的 PIN 码 ”。 如 果 
PIN 码 第 三 次 输入 无 效 、 卡 片 被 盗 或 卡片 过 期 ， 则 状态 机 转换 为 “没收 卡片 ”的 状态 ， 动 作 是 
吞 卡 。 另 外 一 种 情况 是 ， 同 一 事件 可 以 导致 不 同 状 态 下 的 状态 转换 ， 并 且 在 每 种 状态 下 都 具有 
相同 的 动作 。 例 如 图 10-9 中 ， 在 三 种 状态 “等 待 PIN 码 ” “验证 PIN 码 ” 和 “等 待 客户 选择 ” 
中 的 任 一 状态 下 ， 客 户 可 能 决定 选择 “取消 ”， 这 样 会 导致 系统 退出 卡片 并 进入 “ 退 卡 ”状态 。 





Card Inserted / 
Get PIN 








PIN Entered / Invalid PIN / Invalid PIN Prompt 
Validate PIN 
Third Invalid PIN, 
Card Stolen, Card Expired / 
Confiscate 













Valid PIN / 
Display Menu 


图 10-8 ”可 替换 状态 转换 和 动作 示例 
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Cancel / Eject 
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Card Stolen, Card Expired / 
Confiscate 
Validating PIN Confiscating 
Valid PIN / - 
Display Menu Cancel / Eject 













Waiting for 
Customer Choice 





Cancel / Eject 


图 10-9 不 同 状态 转换 中 相同 的 事件 和 动作 示例 
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10.4.2 ”进入 动作 


进入 动作 是 指 在 开始 进入 该 状态 时 触发 的 即时 动作 。 进 入 动作 通过 保留 字 “ 进 入 ” 
(entry) 来 表示 ， 在 状态 框 里 表示 为 “进入 /动作 ”( entry/Action )。 尽 管状 态 转换 动作 ( 动作 
显 式 地 表示 在 状态 转换 上 ) 总 是 被 使 用 到 ， 但 是 进入 动作 只 会 在 某 些 情况 下 被 使 用 到 。 使 用 
进入 动作 的 场合 如 下 : 

© 有 多 个 状态 转换 进入 该 状态 。 

° 在 每 次 状态 转换 进入 该 状态 时 都 需要 执行 同一 动作 。 

ө 某 一 动作 在 进入 该 状态 时 执行 ， 而 在 前 一 状态 退出 时 不 执行 。 

在 上 述 情况 下 ， 动 作 只 能 显示 在 状态 框 内 ， 而 不 是 显示 在 进入 该 状态 的 每 个 状态 转换 中 。 
另外 ， 如 果 动 作 只 是 在 某 些 状态 转换 时 执行 ， 而 在 其 他 状态 转换 时 不 执行 ， 这 样 就 不 要 使 用 
进入 动作 。 同 时 ， 转 换 动作 应 该 使 用 在 相关 联 的 状态 转换 中 。 

图 10-10 给 出 了 进入 动作 的 示例 。 在 图 10-10a 中 ， 动 作 显 示 在 状态 转换 上 。 当 微波 炉 
处 于 “准备 豪 饪 ”状态 时 ， 如 果 开 始 按钮 被 按 下 (触发 事件 “开始 ”)， 状 态 图 转换 为 “正在 
HEE” RAS. ERARA : “НЕ” (Start Cooking) 和 “计时 器 开始 计时 ”( Start 
Timer )。 另 一 方面 ， 当 处 于 “ 门 关闭 并 放 有 食物 ”状态 时 ， 如 果 用 户 按 下 “+” 按 钮 EE 
食物 一 分 钟 )， 状 态 图 也 会 转换 到 “正在 毫 饪 ”状态 。 然 而 ， 该 情况 下 对 应 的 动作 是 “开始 豪 
饪 ”和 “增加 的 时 间 开 始 计时 ”( Start Мише )。 因 此 ， 在 两 种 状态 都 转换 到 “正在 豪 饪 ” 状 
态 时 ， 有 一 个 动作 (“Я”) 是 相同 的 ， 但 是 第 二 个 动作 却 不 同 。 一 种 可 替换 方案 是 将 
“开始 豪 饪 ”作为 进入 动作 ， 如 图 10-10b HR, HHA “EERE” RAEN, AIE “F 
始 豪 饪 ”开始 执行 ， 因 为 该 动作 是 在 每 次 转换 为 该 状态 时 执行 。 然 而 ,动作 “ 计 时 器 开始 计 
时 ”显示 为 从 状态 “准备 毫 饪 ”转换 为 状态 “正在 烹饪 ”时 的 动作 。 这 是 因为 动作 “计时 器 
开始 计时 ”只 有 在 特定 的 转换 为 “正在 豪 饪 ”状态 时 执行 ， 而 在 其 他 的 状态 转换 时 不 执行 。 
因此 ， 当 从 状态 “ 门 关闭 并 放 有 食物 ”转换 为 状态 “正在 亮 饪 ”时 ， 转 换 动 作 是 “增加 的 时 
间 开 始 计时 ”。 图 10-10a 和 图 10-10b 在 语义 上 是 等 价 的 ， 但 是 图 10-10b 更 简洁 。 
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Start Cooking, 
Start Minute 
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Door Shut with 


Ready to Cook 


Door Shut with 
Item 






Cooking 


Entry / 
Start Cooking 





Start / 





Start Cooking, Start / Ready to Cook 
Start Timer Start Timer 
a) 状态 转换 上 的 动作 b) 进入 动作 
图 10-10 进入 动作 示例 
10.4.3 ”退出 动作 


退出 动作 是 指 在 离开 该 状态 时 触发 的 即时 动作 。 退 出 动作 通过 保留 字 “ 退 出 ”( exit ) 来 
表示 ， 在 状态 框 里 表示 为 “退出 /动作 ”(exit/Action )。 尽 管状 态 转 换 动作 ( 动作 显 式 地 表示 
在 状态 转换 上 ) 总 是 被 使 用 到 ， 但 是 退出 动作 只 会 在 某 些 情况 下 被 使 用 到 。 使 用 退出 动作 的 
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场合 如 下 : 

° 有 多 个 状态 转换 来 退出 该 状态 。 

• 在 每 次 状态 转换 退出 该 状态 时 都 需要 执行 同一 动作 。 

o 某 一 动作 在 退出 该 状态 时 执行 ， 而 在 下 一 状态 进入 时 不 执行 。 

在 上 述 情 况 下 ， 动 作 只 能 显示 在 状态 框 内 ， 而 不 是 显示 在 退出 该 状态 的 每 个 状态 转换 中 。 
另外 ， 如 果 动 作 只 是 在 某 些 状态 转换 中 执行 ， 而 在 其 他 状态 转换 时 不 执行 ， 这 样 就 不 要 使 用 
退出 动作 。 同 时 ， 转 换 动作 应 该 使 用 在 相关 联 的 状态 转换 中 。 

图 10-11 给 出 了 退出 动作 的 示例 。 在 图 10-11a 中 ， 动 作 显 示 在 退出 “正在 毫 饪 ”状态 的 
状态 转换 上 。 考 虑 动作 “停止 豪 饪 ”( Stop Cooking )， 如 果 计 时 器 超时 ， 微 波 炉 将 从 状态 “ 正 
在 烹饪 ”转换 为 状态 “ 门 关 闭 并 放 有 食物 ”， 并 有 生动 作 “停止 毫 饪 ”被 执行 (图 10-11a )。 如 
果 门 被 打开 ， 微波炉 将 会 从 状态 “正在 毫 饪 ”转换 为 状态 “ 门 打 开 并 放 有 食物 ”。 在 该 状态 
转换 中 ， 两 个 动作 被 执行 :“ 停 止 训 饪 ”和 “计时 器 停止 计时 ”( Stop Timer )。 因 此 ， 在 离开 
“EERIE” {КЖ (图 10-11a ) 的 两 种 状态 转换 中 ,动作 “ 停 止 襄 饪 ”都 被 执行 。 然 而 ， 当 门 
被 打开 ， 状 态 转换 为 “ 门 打 开 并 放 有 食物 ”， 此 时 有 另外 一 个 动作 “计时 器 停止 计时 ”。 图 10-116 
展示 了 另外 一 个 可 替换 的 设计 ， 其 中 包括 退出 动作 “停止 亮 饪 "。 这 意味 着 当 有 离开 状态 “ 正 
在 亮 饪 ”的 状态 转换 时 ， 退 出 动作 “停止 亮 饪 ”就 会 执行 。 另 外 ， 在 转换 为 “ 门 打 开 并 放 有 
食物 ”状态 时 ， 转 换 动作 “计时 器 停止 计时 ”也 会 执行 。 如 图 10-11b 所 示 ， 与 将 动作 显示 在 
状态 转换 中 相 比 ， 将 动作 “停止 豪 饪 ”作为 退出 动作 会 更 简洁 。 而 在 图 10-11a 中 ， 动 作 “ 停 
止 豪 饪 ”必须 显 式 地 展示 在 每 个 离开 状态 “正在 亮 饪 ”的 状态 转换 中 。 图 10-11a 和 图 10-11b 
在 语义 上 是 等 价 的 ， 但 是 图 10-11b 更 简洁 。 
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a) 状态 转换 上 的 动作 b) 退出 动作 


图 10-11 退出 动作 示例 


10.5 ”层次 化 状态 图 


扁平 化 状态 图 潜在 的 一 个 问题 是 ， 随 着 状态 和 状态 转换 的 不 断 增长 ， 状 态 图 会 变 得 杂乱 
并 难以 阅读 。 为 了 简化 状态 图 并 增加 其 建 模 能 力 ， 引 入 复合 状态 和 状态 图 的 层次 化 分 解 是 很 
重要 的 方法 。 复 合 状 态 也 被 称 为 超级 状态 。 通 过 这 种 方法 ， 状 态 图 中 某 个 层次 的 复合 状态 可 
被 分 解 为 低层 次 状态 图 中 的 两 个 或 多 个 子 状态 。 

层次 化 状态 图 的 提出 是 为 了 探索 状态 转换 图 的 基本 概念 和 可 视 化 优势 ， 同 时 通过 层次 化 
的 结构 来 克服 过 度 复杂 和 混乱 的 状态 图 存在 的 劣势 。 需 要 注意 的 是 ， 每 一 个 层次 化 状态 图 都 
可 以 映射 为 一 个 扁平 化 状态 图 ， 所 以 针对 每 个 层次 化 状态 图 ， 都 存在 一 个 语义 上 等 价 的 扁平 
化 状态 图 。 
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10.5.1 层次 化 状态 分 解 


通过 对 状态 的 层次 化 分 解 ， 状 态 图 可 以 得 到 显著 的 简化 ， 此 时 ， 复 合 状 态 被 分 解 为 两 个 或 
多 个 相互 关联 并 有 先后 顺序 的 子 状态 。 这 种 分 解 称 为 “顺序 化 状态 分 解 "。 对 状态 分 解 的 表示 依 
赖 于 分 解 的 复杂 度 ， 可 以 将 复合 状态 和 子 状态 显示 在 同一 个 图 中 ， 也 可 以 显示 在 单独 的 图 中 。 

层次 化 状态 分 解 的 一 个 实例 如 图 10-12a 所 示 ， 复 合 状态 “处 理 客 户 输 入 ”( 了 Processing 
Customer Input) 包含 三 个 子 状态 :“ 等 待 PIN W”, “验证 PIN 码 ” 和 “等 待 客 户 选 择 "。( 在 
层次 化 状态 图 中 ， 复 合 状态 用 外 圆 角 方 框 表示 ， 复 合 状态 的 名 称 显示 在 方 框 的 左上 角 ， 子 状 
态 用 内 圆 角 方 框 表 示 。) 当 系 统 处 于 复合 状态 “处 理 客户 输入 ”时 ， 它 处 于 “等 待 PIN 码 ”、 
“验证 PIN 码 ” 和 “等 待 客户 选择 ”中 的 某 一 个 子 状 态 。 因 为 子 状 态 是 顺序 执行 的 ， 所 以 该 类 
型 的 层次 化 状态 分 解 导 致 了 “顺序 化 状态 图 ”的 产生 。 


10.5.2 ”复合 状态 


复合 状态 在 状态 图 中 有 两 种 表示 方式 。 第 一 种 方式 是 ， 一 个 复合 状态 可 以 和 其 内 部 子 状 
态 一 起 显示 出 来 ， 例 如 图 10-12a 中 的 复合 状态 “处 理 客户 输入 "。 另 外 一 种 方式 是 ， 复 合 状态 
可 以 表示 为 一 个 黑 盒 ， 不 透露 其 内 部 子 状态 ， 如 图 10-12b 所 示 。 需 要 指出 的 是 ， 当 复合 状态 
被 分 解 为 多 个 子 状态 时 ， 必 须要 保留 进入 和 离开 该 复合 状态 的 状态 转换 。 因 此 ， 如 图 10-12a 
和 图 10-12b 所 示 ， 复 合 状态 “处 理 客户 输入 ”有 一 个 进入 该 状态 的 状态 转换 和 两 个 退出 该 状 
态 的 状态 转换 。 

每 个 进入 复合 状态 “处 理 客户 输入 ”的 状态 转换 实际 上 是 进入 更 低层 次 状态 图 中 的 某 一 
个 子 状态 。 每 个 复合 状态 的 状态 转换 实例 实际 上 必须 源 自 更 低层 次 状态 图 中 的 某 一 个 子 状态 。 
因此 ， 输 入 事件 “卡片 被 插入 ”会 使 状态 转换 为 复合 状态 “处 理 客户 输入 ”中 的 子 状态 “等 
待 PIN #3”, АЕ 10-12а 所 示 。 从 复合 状态 “处 理 客户 输入 ”转换 为 状态 “没收 卡片 "， 此 状 
态 转 换 实际 上 源 自 子 状态 “验证 PIN 码 ”， 如 图 10-12a 所 示 。 下 节 将 介绍 进入 “ 退 卡 ”状态 
的 “取消 ”转换 的 情况 。 


10.5.3 ”状态 转换 的 聚合 


层次 化 状态 图 表示 法 也 允许 如 下 转换 : 状态 图 中 离开 每 个 子 状态 的 状态 转换 可 以 聚合 成 
离开 复合 状态 的 状态 转换 。 巧 妙 地 使 用 该 特征 ， 可 显著 减少 状态 图 中 状态 转换 的 数量 。 

考虑 状态 转换 的 聚合 在 以 下 示例 中 的 作用 。 在 图 10-9 所 示 的 扁平 化 状态 图 中 ， 客 户 可 能 
会 在 三 种 状态 “等 待 PIN W”, “WUE PIN 码 ” 和 “等 待 客户 选择 ”中 的 任 一 状态 下 按 下 АТМ 
机 上 的 “取消 ”按钮 。 在 任 一 情况 下 ,“ 取 消 ” 事 件 将 会 使 ATM 转换 为 “ 退 卡 ” 状 态 。“ 取 
消 ” 将 会 使 ATM 离开 这 三 种 中 的 任 一 状态 ， 继 而 进入 “ 退 卡 ”状态 。 

通过 层次 化 状态 图 对 其 进行 表示 会 更 简洁 。 当 处 于 复合 状态 “处 理 客户 输入 ”的 三 种 子 
状态 中 的 任 一 状态 时 ， 输 入 事件 “取消 ”都 会 使 状态 转换 为 “ 退 卡 ”。 因 为 事件 “取消 ”会 在 
“处 理 客户 输入 ”三 个 子 状态 中 的 任 一 状态 出 现 ,“ 取 消 ”转换 则 可 表示 为 离开 每 一 个 子 状 态 。 
然而 ， 通 过 状态 转换 “取消 ”来 表示 离开 复合 状态 “处 理 客 户 输入 ”会 更 简洁 ， 如 图 10-12a 
所 示 。 离 开 这 些 子 状态 的 转换 没有 在 此 显示 (即使 转换 实体 源 自 子 状态 )。 在 这 种 状态 转换 
中 ， 同 一 事件 会 导致 多 个 状态 转换 为 另外 的 状态 ， 这 种 状态 转换 在 扁平 化 状态 图 和 状态 转换 
图 中 会 产生 过 多 的 弧 线 。 
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b) 
Al 10-12 层次 化 状态 图 示例 


与 之 相反 ， 由 于 事件 “第 三 次 验证 无 效 ” 只 会 发 生 在 状态 “验证 PIN 码 ” 中 (图 10-12a )， 
所 以 它 显示 为 只 离开 该 子 状态 而 不 是 整个 复合 状态 。 





10.5.4 正 交 状态 图 


另外 一 种 层次 化 分 解 是 正 交 状态 分 解 ， 它 用 来 从 不 同 的 视角 对 同一 对 象 状 态 进 行 建 模 。 
在 这 个 方法 中 ， 状 态 图 中 高 层次 的 状态 可 分 解 为 两 个 (或 更 多 ) 正 交 状态 图 。 两 个 正 交 状态 
图 通过 一 条 虚线 隔 开 。 当 高 层次 的 状态 图 处 于 复合 状态 时 ， 它 同时 也 处 于 第 一 个 较 低 层次 的 
正 交 状态 图 中 的 某 一 子 状 态 ， 也 处 于 第 二 个 较 低层 次 的 正 交 状 态 图 中 的 某 一 子 状态 。 
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尽管 正 交 状态 图 可 以 用 来 在 包含 状态 图 的 对 象 中 表示 并 发 的 活动 ， 但 最 好 使 用 这 种 分 解 
方法 来 显示 同一 对 象 的 不 同 部 分 (这些 部 分 不 是 并 发 的 )。 设 计 只 有 一 个 控制 线程 的 对 象 会 更 
简单 ， 强 烈 推荐 使 用 该 方式 。 当 确实 需要 使 用 并 发 时 ， 则 使 用 分 离 的 对 象 并 且 为 每 个 对 象 定 
义 各 自 的 状态 图 。 

可 以 通过 ATM 的 例子 来 说 明 如 何 通 过 正 交 状态 图 来 表示 条 件 。 如 图 10-13 所 示 ，ATM 
BLP “АТМ 控制 ”( ATM Control ) 的 状态 图 被 分 解 为 两 个 正 交 的 状态 图 ， 一 个 用 于 “ATM Е 
流程 ”( ATM Sequencing )， 另 外 一 个 用 于 “关闭 请 求 条 件 ”( Closedown Request Condition )。 
这 两 个 状态 图 是 高 层次 的 状态 图 ， 通 过 虚线 分 割 开 来 。“ATM 主流 程 ”状态 图 实际 上 是 ATM 
的 主要 状态 图 ， 用 来 显示 当 处 理 客户 请 求 时 所 经 历 的 各 种 状态 。 


ATM Control 


ATM Sequencing 










ATM 
Sequencing 
Composite State 


Closedown Request Condition 
Closedown Not Requested 


Closedown Was Requested 


Æ 10-13 ATM 中 的 正 交 状态 图 示例 









需要 注意 的 是 ， 在 任何 时 刻 ， 复 合 状态 “ATM 控制 ”处 于 “ATM 主流 程 ” 状 态 图 中 
的 某 一 子 状态 ， 同 时 也 处 于 “关闭 请 求 条 件 ” 状 态 图 中 的 某 一 子 状态 。“ 关 闭 请 求 条 件 ” 是 
一 个 简单 的 状态 图 ， 有 两 个 状态 ， 标 明 关 闭 是 否 被 请 求 ,“ 关 闭 未 被 请 求 ”( Closedown 
Not Requested ) 是 初始 化 状态 。 事 件 “ 关 闭 ”( Closedown ) 会 使 状态 转换 为 “关闭 被 请 
求 ”( Closedown Was Requested )， 事 件 “ 开 启 ”( Startup ) 会 使 状态 回 到 “关闭 未 被 请 
Ж”. “АТМ 控制 ”的 状态 图 是 “ATM 主流 程 ”状态 图 和 “关闭 请 求 条 件 ” 状 态 图 的 结合 。 
当 АТМ 处 于 状态 “正在 终止 ”( Terminating ) 时 接收 到 事件 “已 过 时 间 ”( after ( Elapsed 
Time )),“ 关 闭 请 求 条 件 ” 状 态 图 中 的 状态 “关闭 被 请 求 ” 和 “关闭 未 被 请 求 ” 将 成 为 
“ATM 主流 程 ” 状 态 图 中 被 检查 的 条 件 。 注 意 ， 状 态 “ 关 闭 ” 实 际 上 是 “ATM 主流 程 ” 状 
态 图 中 的 一 个 状态 。 


10.6 ”开发 状态 图 的 指导 原则 
以 下 所 列举 的 指导 原则 可 用 于 开发 扁平 化 状态 图 或 层次 化 状态 图 ， 除 非 男 有 明确 说 明 : 
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© 当 系 统 中 正在 发 生 某 些 事 情 时 ， 状 态 名 称 必须 反映 可 识别 的 情况 或 一 段 时 间 间 隔 。 因 
此 ， 状 态 名 经 常 是 形容 词 ( 例如 : Idle), 形容 词 短语 〈《 例 如 : ATM Idle )、 动 名 词 ( 例 
如 : Dispensing ) 或 动 名 词 短 语 (例如 : Waiting for PIN )。 同 时 ,状态 名 不 应 该 反映 
事件 或 动作 ， 例 如 ATM Dispenses 或 Dispense Cash. 

在 给 定 的 状态 图 上 ， 每 一 个 状态 要 有 唯一 的 名 称 。 两 个 状态 有 相同 的 名 称 将 会 产生 歧 
义 。 理 论 上 来 说 ， 在 不 同 的 复合 状态 之 间 ， 各 自 的 子 状态 可 以 有 相同 的 名 称 。 然 而 这 
种 情况 会 导致 难以 理解 ， 因 此 最 好 避免 该 情况 。 

必须 要 能 从 各 个 状态 退出 。 由 于 状态 图 可 能 表示 系统 或 对 象 的 持续 运行 ， 因 此 一 个 状 
态 图 不 必 都 有 终止 状态 。 

在 顺序 状态 图 中 ， 状 态 图 在 任 一 时 刻 只 能 处 于 一 种 状态 中 。 两 个 状态 不 能 同时 被 激活 
(例如 :“ 等 待 РІМ 码 ” 和 “出 钞 ”)。 各 个 状态 必须 按 顺序 执行 。 

不 要 混淆 事件 和 动作 。 事 件 是 产生 状态 转换 的 原因 ， 而 动作 是 状态 转换 的 作用 和 
效果 。 

事件 发 生 在 某 一 时 刻 。 事 件 的 名 称 表 明 某 些 事情 刚刚 发 生 ( 例如 :“ 卡 被 插入 ”,“ 门 被 
关闭 ”) 或 动作 的 结果 ， 例 如 :“ 有 效 PIN 码 ” 或 “第 三 次 无 效 PIN 码 ”。 

ө ЗЕ Ло. И: “НР”, “ЖАЙЫК”, ЗН”. 

o 动作 是 瞬间 执行 的 。 同 一 状态 转换 可 能 会 关联 多 个 动作 。 这 些 动 作 从 概念 上 来 说 是 同 
时 执行 的 ， 因 此 ， 不 能 假设 这 些 动 作 执行 的 顺序 。 因 此 ， 这 些 动 作 之 间 必 须 不 存在 相 
互 依赖 的 关系 。 如 果 存 在 依赖 ， 则 需要 引入 中 间 状 态 来 解决 。 

条 件 是 布尔 值 。 如 果 状 态 转换 被 标识 为 事件 [条 件 ]， 那 么 只 有 事件 发 生 并 且 条 件 为 
真 时 才 会 发 生 该 状态 转换 。 条 件 在 某 一 段 时 间 间 隔 中 值 为 真 。“ 门 关闭 [剩余 时 间 不 为 
0]” 表 示 只 有 当 门 关闭 并 且 剩 余 有 限 的 时 间 时 ， 该 状态 转换 才 会 发 生 。 如 果 门 关闭 但 
剩余 时 间 为 零 ， 则 该 状态 转换 不 会 发 生 。 

动作 和 条 件 是 可 选 的 。 只 有 必要 时 才 会 使 用 它们 。 
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要 从 用 例 来 开发 状态 图 ， 首 先 需 要 用 例 中 的 一 个 特定 的 场景 ， 即 用 例 中 的 一 条 特定 路 径 。 
理想 情况 下 ， 这 个 场景 应 该 是 贯穿 整个 用 例 的 主 序列 ， 涉 及 参与 者 和 系统 之 间 交 互 的 最 常用 
序列 。 现 在 考虑 给 定 的 场景 下 外 部 事件 的 顺序 。 通 常 ， 一 个 外 部 环境 中 的 输入 事件 会 引起 状 
态 转换 到 一 个 新 的 状态 ， 该 状态 转换 的 名 称 和 状态 中 发 生 的 事情 相对 应 。 如 果 一 个 动作 和 该 
状态 转换 相关 联 ， 则 从 一 个 状态 转换 为 另外 一 个 状态 时 触发 该 动作 。 动 作 由 用 例 中 描述 的 系 
统 对 输入 事件 的 响应 来 决定 。 

最 初 ， 扁 平 化 状态 图 被 开发 出 来 ， 该 状态 图 包括 主场 景 中 给 出 的 事件 顺序 。 状 态 图 中 的 
状态 应 该 全 部 是 外 部 可 见 的 状态 ， 即 参与 者 可 以 看 到 每 个 状态 。 实 际 上 ， 这 些 状态 表示 参与 
者 直接 或 间接 进行 的 操作 的 结果 。 在 下 一 节 中 给 出 的 详细 示例 将 说 明 这 一 点 。 

要 完成 状态 图 ， 需 要 确定 该 状态 图 中 所 有 可 能 输入 的 外 部 事件 。 通 过 考虑 用 例 中 所 有 可 
替换 路 径 的 描述 来 完成 这 个 部 分 。 某 些 可 替换 路 径 描述 了 系统 对 参与 者 的 可 替换 输入 做 出 的 
反应 。 确 定 初始 状态 图 中 每 个 状态 中 的 事件 的 作用 。 很 多 情况 下 ， 一 个 事件 在 给 定 的 状态 下 
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不 会 发 生 或 没有 产生 影响 。 然 而 在 其 他 状态 中 ， 一 个 事件 的 到 来 将 导致 状态 转换 为 一 个 现 有 
状态 ， 或 转换 为 某 些 新 状态 ， 这 些 新 状态 需要 加 入 到 状态 图 中 。 需 要 考虑 从 每 个 可 替换 状态 
转换 中 产生 的 动作 。 这 些 动作 应 该 已 经 被 包含 在 用 例 的 描述 中 ， 并 且 这 些 动作 表示 系统 对 多 
种 可 替换 输入 事件 做 出 的 反应 。 

在 某 些 应 用 中 ， 一 个 状态 图 会 参与 多 个 用 例 。 在 这 种 情况 下 ， 每 个 用 例 将 对 应 一 个 部 
分 的 状态 图 。 可 以 将 这 些 部 分 的 状态 图 集成 起 来 从 而 形成 一 个 完整 的 状态 图 。 言 下 之 意 ， 在 
(至 少 某 些 ) 用 例 和 其 对 应 的 状态 图 执行 时 将 有 优先 级 。 若 要 集成 两 个 部 分 的 状态 图 ， 则 需要 
找到 一 个 或 多 个 公有 状态 。 一 个 公有 状态 可 能 是 一 个 状态 图 的 最 后 状态 ， 并 且 是 下 一 个 状态 
图 的 开始 状态 。 然 而 ， 也 存在 其 他 情况 。 集 成 的 方法 是 通过 公有 状态 集成 部 分 的 状态 图 ， 从 
而 将 第 二 个 状态 图 的 公有 状态 释 加 到 第 一 个 状态 图 相同 的 状态 上 。 上 述 方法 可 按 需 要 重复 使 
用 ， 这 依赖 于 有 多 少 个 部 分 状态 图 需要 集成 。 

有 了 完整 的 扁平 化 状态 图 ， 下 一 步 就 是 要 开发 展 次 化 状态 图 。 实 际 上 有 两 种 方法 来 开 
发 层次 化 状态 图 。 第 一 种 方法 是 通过 自 项 向 下 的 方法 来 确定 主要 的 高 层次 状态 ， 有 时 被 称 作 
“操作 模式 ”。 例 如 ， 在 飞机 控制 状态 图 中 ， 模 式 可 能 包括 起 飞 、 飞 行 中 和 着 陆 。 每 种 模式 包 
含 一 些 状 态 ， 其 中 一 些 也 可 能 是 复合 状态 。 这 种 方法 经 常 使 用 在 复杂 的 实时 系统 中 ， 而 这 些 
实时 系统 经 常 都 是 与 状态 高 度 相关 的 。 第 二 种 方法 是 首先 开发 扁平 化 状态 图 ， 接 着 确定 可 以 
被 聚合 成 复合 状态 的 状态 ， 如 10.8.4 节 所 述 。 
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Customer Choice 


108 从 用 例 开 发 状态 图 示例 
10.8.1 为 每 个 用 例 开 发 状态 图 (№ ү 
а пѕе! Entry / 
521®АШТ “MRR Ф сарм, 
“验证 PIN 码 ” 和 “ 取 钱 ”"。 这 两 个 用 例 
描述 了 参与 者 ( ATM 的 客户 ) 与 系统 
码 ” 在 “ 取 钱 ”之 前 。 图 10-14 和 10-15 Validate PIN 
展示 了 每 一 个 用 例 的 状态 图 。 图 10-14 
状态 图 ， 在 该 用 例 场 景 中 ，PIN 码 是 有 
效 的 ， 如 10.4.1 节 所 述 。 该 状态 图 从 状 。 vag pany 
Update Status 
户 选 择 ”。 
图 10-15 展示 了 与 用 例 “ 取 款 ” 主 
“等 待 客户 选择 ”开始 。 在 主场 景 中 ， 图 10.14 “АТМ 控制 ”的 状态 图 :“ 验 证 PIN 码 ”用 例 
取款 被 选择 ( 导致 状态 转换 为 “处 理 取 


为 了 阐明 如 何 从 用 例 开 发 出 状态 图 ， 考 虑 “银行 系统 ”案例 中 的 АТМ 控制 状态 图 。 
用 例 。 在 这 个 例子 中 ， 我 们 考虑 用 例 
之 间 交 互 的 先后 顺序 ， 其 中 “验证 PIN Ce 
展示 了 用 例 “ 验 证 PIN 码 ” 主 序列 的 
态 “ 空 闸 ” 开 始 ， 结 束 于 状态 “等 待 客 та 
场景 对 应 的 状态 图 。 这 个 状态 图 从 状态 
款 ” )， 取 款 被 批准 ( 导致 状态 转换 为 “出 钞 ” )， 出 钞 ( 导致 状态 转换 为 “打印 )， 任 条 被 打 
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印 〈 导 致 状态 转换 为 “ 退 卡 ” )， 卡 片 被 退出 ， 状 态 转换 为 “终止 " ， 经 过 一 段 固定 长 度 的 时 间 
Ја, RARE “FSA” {Хх 
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Eject 


Waiting for 
Customer Choice 






Withdrawal Selected / 






Request Withdrawal, дрена ' 
Display Wait Display Cash Dispensed, 
Confirm Cash Dispensed 






Processing А Е 


Я 10-15 “АТМ 控制 ”的 状态 图 :“ 取 款 ” 用 例 


Withdrawal Approved / 
Dispense Cash, 
Update Status 


在 上 述 例子 中 ，ATM 状态 图 中 的 状态 都 是 外 部 可 见 的 ， 即 参与 者 能 看 见 所 有 的 状态 。 实 
际 上 ， 状 态 显示 了 参与 者 直接 或 间接 进行 的 操作 顺序 。 


10.8.2 ”考虑 可 替换 序列 


当 完 成 最 初 的 状态 图 后 ， 接 下 来 要 对 其 进行 细 化 。 要 完成 状态 图 ， 需 要 考虑 用 例 中 可 替 
换 部 分 描述 的 对 每 个 可 替换 序列 的 影响 。 图 10-9 展示 了 验证 PIN 码 的 状态 图 ， 该 状态 图 中 对 
主 序列 增加 了 可 替换 的 序列 ， 如 10.4.1 节 所 述 。 图 10-16 展示 了 取款 的 状态 图 ， 该 状态 图 中 
也 对 主 序列 增加 了 可 替换 的 序列 。 因 此 ， 除 了 出 钞 场景 中 的 主 序列 ， 又 增加 了 两 个 额外 的 场 
Ж: 取款 交易 被 拒绝 ( 直接 从 “取款 ”状态 转换 为 “ 退 卡 ”状态 ) 和 ATM 余额 不 足 (从 “出 
钞 ” 状 态 转 换 为 “关闭 ”状态 )。 


10.8.3 ”开发 集成 的 状态 图 


在 考虑 完 可 替换 序列 后 ， 集 成 的 状态 图 需要 将 基于 用 例 的 状态 图 整合 起 来 。 因 此 ， 图 10-9 
所 示 的 状态 图 (具有 可 替换 序列 的 “验证 PIN 码 ” 用 例 ) 和 图 10-16 ( 具有 可 蔡 换 序列 的 “ 取 
款 ” 用 例 ) 将 和 其 他 用 例 的 状态 图 结合 起 来 。 这 个 状态 图 通过 将 每 个 用 例 合成 起 来 从 而 展现 具 
有 可 替换 序列 的 主 序列 。 

图 10-17 展示 了 集成 的 状态 图 ， 该 状态 图 集成 了 验证 PIN 码 状态 图 和 取款 状态 图 ， 同 时 
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图 10-17 “ATM 控制 ”的 状态 图 : 具有 可 替换 序列 的 集成 了 “验证 PIN 码 ” 和 “取款 ”用 例 的 状态 图 
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具有 主 序列 和 可 替换 序列 。 主 要 的 状态 图 集成 点 是 状态 “等 待 客户 选择 "， 它 是 验证 PIN 码 状 
态 图 的 结束 状态 ， 同 时 也 是 取款 ( 和 转账 、 账 户 查 询 ) 状态 图 的 初始 状态 。 另 外 ， 其 他 的 状 
态 图 集成 点 是 验证 PIN 码 的 可 替换 场景 中 的 状态 “ 退 卡 ”和 “没收 卡片 ”。 


10.8.4 ”开发 层次 化 状态 图 


初始 情况 下 ， 开 发 一 个 扁平 化 状态 图 通常 是 容易 的 。 通 过 考虑 可 替换 事件 可 优化 扁平 化 
状态 图 ， 在 这 之 后 通过 开发 层次 化 状态 图 来 简化 状态 图 。 查 找 可 以 聚合 的 状态 ， 因 为 它们 能 
组 合成 一 个 复合 状态 。 特 别 地 ， 查 找 那 些 状态 聚合 能 简化 状态 图 的 情况 。 

“ATM 控制 ”的 层次 化 状态 图 显示 在 图 10-18 至 图 10-21 中 。 图 10-18 中 的 三 个 状态 是 
复合 状态 :“ 处 理 客户 输入 ”( 被 分 解 为 图 10-19 中 的 三 个 子 状态 ),“ 处 理 交 易 ”( Processing 
Transaction ) ( 被 分 解 为 图 10-20 中 的 三 个 子 状态 ) 和 “终止 交易 ”( Terminating Transaction ) 
(被 分 解 为 图 10-21 中 的 五 个 子 状 态 )。 复 合 状态 “处 理 客 户 输入 ”主要 进行 状态 转换 的 聚合 
(图 10-18 )。 特 别 地 ,“ 取 消 ”事件 被 聚合 到 复合 状态 的 转换 中 ， 而 不 是 三 个 子 状 态 的 转换 中 。 
状态 转换 的 聚合 也 应 用 在 复合 状态 “处 理 交 易 ” 中 (图 10-19 )， 事 件 “ 拒 绝 ” 从 对 离开 子 状 
态 的 转换 聚合 为 对 离开 复合 状态 的 转换 。 在 复合 状态 “终止 交易 ”中 ,包含 了 与 结束 交易 相 
关 的 子 状态 ,例如 :出 钞 、 打 印 任 条 和 退出 ATM 卡 。 它 也 包括 取消 交易 和 终止 交易 的 子 状态 。 
第 21.6 节 将 对 该 状态 图 进行 更 详细 的 描述 。 
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Н 10-18 “АТМ 控制 ”的 高 层次 状态 图 
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FA 10-19 “ATM 控制 ”的 状态 图 :“ 处 理 客户 输入 ”的 复合 状态 
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图 10-20 “ATM 控制 ”的 状态 图 :“ 处 理 交易 ”的 复合 状态 
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Dispense Cash, 
Update Status 











Display Wait 
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10.9 BE 
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随后 详细 描述 了 从 用 例 开发 状态 图 的 过 程 。 一 个 状态 图 可 能 支持 多 个 用 例 ， 每 个 用 例 组 成 
状态 图 的 子 集 。 这 种 情况 也 可 通过 如 下 方法 解决 : 将 状态 图 和 对 象 交 互 模型 结合 起 来 ， 其 中 
状态 相关 的 控制 对 象 执行 状态 图 ， 这 将 在 第 11 章 中 被 阐述 。 状 态 图 的 示例 同样 来 自 于 “ 银 
行 系统 ”。 
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зидања Ae | Confirm Cash Dispensed 
Н 10-21 “АТМ 控制 ”的 状态 图 :“ 终 止 交 易 ” 的 复合 状态 

练习 

选择 题 ( 每 道 题 选 择 一 个 答案 ) 

1. 什么 是 状态 机 中 的 状态 ? 

(a) 存在 于 一 段 时 间 间 隔 内 的 可 识别 的 情境 (b) 值 为 真 或 假 的 条 件 
(с) 来 自 外 部 环境 的 输入 (а) 来 自 系统 的 输出 

2. 什么 是 状态 机 中 的 事件 ? 
(а) 导致 状态 发 生 改变 的 离散 信号 (b) 来 自 外 部 环境 的 输入 
(с) 值 为 真 或 假 的 输入 (а) 状态 转换 的 结果 

3. 什么 是 状态 机 中 的 动作 ? 

(a) 在 某 一 时 间 点 发 生 的 事情 (b) 状态 转换 的 原因 

(с) 两 个 连续 事件 之 间 的 间隔 (а) 作为 状态 转换 的 结果 执行 的 运算 


4. 什么 是 状态 机 中 的 进入 动作 ? 

(а) 当 进 入 状态 时 执行 的 动作 

Cb) 当 离 开 状 态 时 执行 的 动作 

(с) 当 进入 状态 时 开始 执行 并 在 离开 状态 时 完成 执行 的 动作 
(а) 作为 状态 转换 的 结果 执行 的 动作 
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5. 什么 是 状态 机 中 的 退出 动作 ? 
(а) 当 进入 状态 时 执行 的 动作 
(b) 当 离 开 状 态 时 执行 的 动作 
(с) 当 进入 状态 时 开始 执行 并 在 离开 状态 时 完成 执行 的 动作 
(4) 作为 状态 转换 的 结果 执行 的 动作 
6. 什么 是 状态 机 中 的 条 件 ? 


(a) 一 个 条 件 性 的 动作 (b) 一 个 条 件 性 的 状态 

(с) 一 个 条 件 性 的 状态 转换 (4) 一 个 条 件 性 的 事件 

7. 进入 复合 状态 的 状态 转换 和 下 面 哪 项 表述 等 价 ? и: 
(а) 进入 唯一 子 状态 的 状态 转换 (b) 进入 每 一 个 子 状态 的 状态 转换 175 
(с) 不 进入 任 一 子 状态 的 状态 转换 (4) 进入 任 一 子 状态 的 状态 转换 

8. 离开 复合 状态 的 状态 转换 和 下 面 哪 项 表述 等 价 ? 

(а) 离开 唯一 子 状态 的 状态 转换 (b ) 离开 每 一 个 子 状态 的 状态 转换 

(с) 不 离开 任 一 子 状 态 的 状态 转换 (а) 离开 任 一 子 状态 的 状态 转换 

9. 复合 状态 如 何 和 子 状态 关联 起 来 ? 

(a) 复合 状态 分 解 为 子 状态 (b) 复合 状态 组 合成 子 状态 

(с) 复合 状态 转换 为 子 状态 (d ) 子 状态 转换 为 复合 状态 


10. 如 果 在 一 个 给 定 的 状态 转换 上 显示 了 两 个 动作 ， 下 面 哪 一 项 是 正确 的 ? 

(а) 两 个 动作 相互 依赖 

(b) 两 个 动作 相互 独立 

(с) 一 个 动作 提供 输入 给 另 一 个 动作 

(а) 当 第 一 个 动作 执行 完毕 后 第 二 个 动作 才 开 始 执行 176 
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状态 相关 的 动态 交互 建 模 能 够 处 理 对 象 间 的 交互 是 与 状态 相关 的 情况 。 状 态 相关 的 交互 
至 少 涉及 一 个 与 状态 相关 的 控制 对 象 ， 通 过 执行 一 个 状态 图 ( 见 第 10 章 的 描述 )， 提 供 了 全 
局 的 控制 ， 并 建立 起 它 与 其 他 对 象 间 的 交互 序列 。 

第 9 章 描述 了 基本 的 动态 交互 建 模 ， 它 是 无 状态 ， 因 此 不 涉及 任何 状态 相关 的 交互 。 在 
对 象 的 构造 过 程 中 ， 会 确定 一 组 参与 某 个 用 例 实现 的 对 象 。 如 果 至 少 有 一 个 对 象 是 与 状态 相 
关 的 控制 对 象 ， 那 么 这 个 交互 就 被 定义 为 状态 相关 的 ， 并 且 应 当 使 用 本 章 中 所 描述 的 状态 相 
关 的 动态 交互 建 模 这 个 术语 。 状 态 相关 的 动态 交互 建 模 是 一 种 在 至 少 涉 及 一 个 状态 相关 控制 
对 象 的 动态 交互 中 用 来 确定 对 象 间 如 何 进行 交互 的 策略 。 在 更 复杂 的 交互 中 ， 有 可 能 存在 多 
个 状态 相关 的 控制 对 象 。 每 个 状态 相关 的 控制 对 象 都 可 以 通过 状态 图 的 方式 来 定义 。 

11.1 节 描 述 状 态 相 关 的 动态 交互 建 模 中 的 步骤 。11.2 节 描 述 如 何在 交互 图 (通信 图 和 顺 
序 图 ) 和 状态 图 上 对 交互 场景 进行 建 模 。11.3 节 则 给 出 了 一 个 基于 “银行 系统 ”的 状态 相关 
的 动态 交互 建 模 的 具体 示例 。 


11.1 状态 相关 的 动态 交互 建 模 中 的 步骤 


在 状态 相关 的 动态 交互 建 模 中 ， 建 模 者 的 目标 是 确定 以 下 对 象 之 间 的 交互 : 

© 执行 状态 机 的 与 状态 相关 的 控制 对 象 。 

ө 对 象 ， 通 常 是 软件 边界 对 象 ， 它 们 向 控制 对 象 发 送 事件 。 这 些 事件 会 导致 控制 对 象 的 

内 部 状态 机 的 状态 转换 。 

© 提供 动作 和 活动 的 对 象 ， 这 些 对 象 被 控制 对 象 由 于 状态 转换 而 触发 。 

• 其 他 参与 实现 用 例 的 对 象 。 

这 些 对 象 间 的 交互 使 用 通信 图 或 顺序 图 描绘 。 

下 面 展示 了 状态 相关 的 动态 交互 建 模 策略 中 的 主要 步骤 。 交 互 的 序列 需要 反映 用 例 中 所 
描述 的 交互 的 主 序列 。 

1) 确定 边界 对 象 。 考 虑 那些 接收 输入 的 对 象 ， 输 入 由 外 部 环境 中 的 外 部 对 象 发 送 。 

2) 确定 状态 相关 的 控制 对 象 。 至 少 有 一 个 执行 状态 图 的 控制 对 象 。 也 可 能 需要 其 他 对 象 。 

3) 确定 其 他 的 软件 对 象 。 这 些 对 象 是 与 控制 对 象 或 边界 对 象 交 互 的 软件 对 象 。 

4) 确定 主 序列 场景 中 的 对 象 交互 。 把 这 一 步 和 第 5 步 一 起 执行 ， 因 为 需要 详细 指定 状态 
相关 的 控制 对 象 和 它 执 行 的 状态 图 之 间 的 交互 。 

5 ) 确定 状态 图 的 执行 。 

6) 考虑 可 替换 序列 场景 。 针 对 由 用 例 的 可 替换 序列 描述 的 场景 ， 执 行 状态 相关 的 动态 分 析 。 


11.2 ”使 用 交互 图 和 状态 图 对 交互 场景 建 模 
本 节 主 要 描述 交互 图 ( 主要 是 通信 图 和 顺序 图 ) 如 何 与 状态 图 共同 用 来 对 状态 相关 的 交 
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互 场景 进行 建 模 (上 述 第 4 步 和 第 5 步 )。 

一 个 交互 图 上 的 消息 包含 一 个 事件 以 及 伴随 该 事件 的 数据 。 在 一 个 具有 执行 状态 图 的 状 
态 相关 控制 对 象 的 场景 中 ,考虑 消息 和 事件 间 的 关系 。 在 一 个 通信 图 中 ， 当 一 个 消息 到 达 控 
制 对 象 的 时 候 ， 该 消息 的 事件 部 分 会 导致 状态 图 中 的 状态 转换 。 状 态 图 中 的 动作 是 状态 转换 
的 结果 ， 也 对 应 着 通信 图 中 描绘 的 输出 消息 。 通 常 来 说 ， 一 个 交互 图 (通信 图 或 顺序 图 ) 中 
的 消息 指 的 是 状态 图 中 的 一 个 事件 。 然 而 ,为 了 简明 起 见 ， 在 描述 状态 相关 的 动态 场景 时 ， 
通常 只 使 用 事件 这 个 术语 。 

源 对 象 向 状态 相关 的 控制 对 象 发 送 事 件 。 输 入 事件 的 到 达 导 致 了 状态 图 上 的 状态 转换 。 
状态 转换 产生 一 个 或 多 个 输出 事件 。 状 态 相关 的 控制 对 象 将 每 个 输出 事件 发 送 给 一 个 目标 对 
象 。 输 出 事件 在 状态 图 中 以 动作 表示 ， 它 可 以 是 一 个 状态 转换 动作 、 一 个 进入 动作 ,或 者 是 
一 个 退出 动作 。 

要 确保 通信 图 和 状态 图 相互 一 致 ， 对 应 的 通信 图 中 的 消息 和 状态 图 中 的 事件 必须 被 赋予 
相同 的 名 称 。 此 外 ， 对 于 一 个 给 定 的 状态 相关 场景 ， 有 必要 在 这 两 张 图 中 使 用 相同 的 消息 编 
号 序列 。 使 用 相同 的 序列 可 以 确保 这 两 张 图 精确 地 展示 了 场景 ， 并 且 可 以 对 场景 的 一 致 性 进 
行 审查 。 后 续 小 节 将 通过 实例 描述 这 些 问 题 。 


11.3 ”状态 相关 的 动态 交互 建 模 示例 : 银行 系统 


本 节 使 用 “银行 系统 ”中 的 一 个 用 例 “ 验 证 PIN 码 ”( Validate PIN) 作为 状态 相关 的 动 
态 交 互 建 模 的 一 个 示例 。 参 与 该 用 例 实现 的 对 象 使 用 对 象 结构 组 织 准则 ( 见 第 8 章 ) 来 确定 。 
在 本 节 中 ， 我 们 首先 考虑 主 序 列 ， 随 后 再 考虑 可 替换 序列 。 


11.3.1 确定 主 序 列 


用 例 “ 验 证 PIN 码 ”( Validate PIN ) 的 主 序列 描述 了 以 下 场景 : 客户 将 ATM FARE 
器 ， 系 统 提示 客户 输入 密码 ， 然 后 系统 会 检查 客户 输入 的 密码 与 系统 保存 的 与 该 ATM 卡号 对 
应 的 密码 是 否 一 致 。 在 主 序列 中 ， 密 码 是 有 效 的 。 

考虑 实现 这 个 用 例 所 需要 的 对 象 。 我 们 首先 确定 需要 对 象 “ 卡 片 读 取 接 口 ”( Card 
Reader Interface ) 用 以 读 取 АТМ Е. М АТМ 卡 中 读 取 的 信息 需要 暂时 存储 起 来 ， 因 此 需要 
定义 一 个 实体 对 象 来 储存 “ATM 卡 ” 的 信息 。“ 客 户 交互 ”( Customer Interaction) 对 象 通 
过 键盘 /屏幕 显示 的 方式 和 客户 进行 交互 ， 在 这 个 示例 中 ， 该 对 象 会 提示 用 户 输入 密码 。 发 
送 给 “银行 服务 ”( Banking Service ) 子 系统 的 用 来 验证 密码 的 信息 被 储存 在 一 个 “ATM 交 
2)” (АТМ Transaction) 中 。 为 了 验证 密码 ， 交 易 信 息 需 要 包含 密码 和 АТМ 卡号 。 为 了 控 
制 动 作 发 生 的 序列 ， 需 要 定义 一 个 控制 对 象 “ATM 控制 ”( ATM Control )。 由 于 控制 对 象 的 
动作 取决 于 之 前 发 生 的 事件 ， 因 此 控制 对 象 应 该 是 状态 相关 的 ， 控 制 对 象 也 因此 需要 执行 一 
个 状态 图 。 

当 客 户 将 АТМ 卡 插 入 到 读 卡 器 时 ,该 用 例 开始 执行 。 消 息 序 列 从 1 开始 编号 ， 正 如 在 
“验证 PIN 码 ” 用 例 中 所 描述 的 那样 ，1 号 消息 是 由 客户 这 个 参与 者 启动 的 第 一 个 外 部 事件 。 
接 下 来 在 序列 中 的 编号 代表 着 系统 对 象 向 参与 者 做 出 反应 ， 编 号 分 别 是 1.1，1.2，1.3， 结 束 
于 1.4， 编 号 为 1.4 的 消息 是 展示 给 参与 者 的 系统 响应 。 来 自 于 参与 者 的 下 一 个 输入 是 被 编号 
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为 2 的 外 部 事件 ， 以 此 类 推 。 一 个 有 效 的 АТМ FEA PN 码 匹配 的 场景 由 图 11-1 所 示 的 通信 
图 表示 ， 同 时 也 由 图 11-2 所 示 的 顺序 图 表示 。 
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Al 11-1 “验证 PIN #3” ( Validate PIN ) 用 例 的 通信 图 :“ 有 效 PIN 码 ” 的 场景 
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Al 11-2 “验证 PIN #3” (Validate PIN) 用 例 的 顺序 图 :“ 有 效 PIN 码 ” 的 场景 
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对 象 交 互 图 上 的 消息 序列 忠实 地 反映 了 用 例 主 序列 中 的 用 例 描 述 。 从 1 到 1.4 的 消息 序列 
自 “ 卡 片 读 取 接口 ”阅读 卡片 开始 ( 消息 1 )， 其 后 是 存储 的 卡片 数据 ( 消息 11), 将 卡片 插入 
的 事件 发 送 给 “ATM 控制 ”对 象 ( 消息 12), 该 消息 导致 状态 的 改变 ， 并 由 控制 对 象 向 “客户 
交互 ”对 象 发 送 “ 获 取 PIN 码 ”( Get PIN) 的 动作 ( 消息 13), 最 后 “客户 交互 ”对 象 在 屏幕 
上 提示 客户 输入 PIN 码 (1.4)。 从 2 到 2.9 的 消息 序列 自用 户 向 “客户 交互 ”对 象 输入 PIN 码 开 
始 (消息 2 )， 其 后 是 检索 卡片 数据 ( 消息 2.1， 消 息 2.2 )， 准 备 PIN 码 验证 交易 ( 消息 2.3， 消 
息 2.4)， 然 后 将 交易 发 送 给 “ATM 控制 ”对 象 ( 消息 2.5 )， 并 从 那里 再 发 送 至 “银行 服务 ” 
(消息 2.6)。 从 1 直至 2.6 的 消息 序列 被 分 组 为 图 11-2 的 顺序 图 ( 如 图 中 标记 为 sd PIN Validation 
的 盒子 所 示 ) 中 的 一 个 “PIN 码 验 证 ”( PIN Validation) 片段 ， 这 个 片段 将 在 后 续 章 节 被 引用 。 
在 这 个 场景 中 ,“ 银 行 服务 ”向 “ATM 控制 ”对 象 发 送 一 个 有 效 PIN 码 的 响应 ( 消息 2.7 )， 该 
消息 最 终 使 得 “客户 交互 ”对 象 将 选择 菜单 在 屏幕 
上 显示 给 客户 ( 消息 2.8 和 消息 2.9 )。 

一 条 到 达 “ATM 控制 ”对 象 的 消息 会 触发 。 1 Cansened/ 


“ATM 控制 ”的 状态 图 上 的 一 次 状态 转换 (图 11-3 ), = 
Waiting for PIN 


Entry / 
Display Welcome 


















例如 ,“ 卡 片 读 取 接口 ”向 “AITM 控制 ”发 送 了 一 
条 “卡片 已 插入 ”( Сага Inserted ) 的 消息 (图 11-1 和 25: PIN entered / 
图 11-2 上 的 消息 1.2 )。 作 为 这 个 事件 (事件 12 对 应 7% Validate PIN 
图 11-1 和 图 11-2 中 的 消息 12， 数 字 1.2 强调 了 消息 
和 事件 之 间 的 对 应 关系 ) ВАНЯ, “АТМ 控制 ”状态 пина 7-7 
图 从 “空闲 ” (Idle ) 状态 (初始 状态 ) 转换 到 “等 aaa the thie 
待 输入 PIN #3” ( Waiting for PIN) 状态 。 与 该 转换 相 
关 的 输出 事件 是 “获取 PIN 码 ”( 事件 13 )。 这 个 输 
出 事件 与 消息 1.3 对 应 ， 该 消息 名 为 “获取 PIN #9”, 
是 由 “ATM 控制 ”对 象 发 送 给 “客户 交互 ”对 象 的 。 图 11-3 “验证 PIN 码 ”(Validate РІМ) 的 

图 11-1 中 的 消息 2.8 和 消息 2.8a 展示 了 一 个 о с В 
并 发 的 序列 。“ATM 控制 ”在 相同 的 状态 转换 中 发 送 了 这 两 条 消息 ， 因 此 这 两 条 消息 序列 有 
可 能 并 发 地 执行 ， 其 中 一 条 发 送 给 “客户 交互 "， 另 一 条 发 送 给 “ATM 交易 ”。 

用 来 描绘 通信 图 ( 见 图 11-1 ) 和 顺序 图 ( 见 图 11-2) 上 消息 的 消息 序列 将 在 21.5 节 的 
“银行 系统 ”案例 研究 中 被 详细 描述 。 


11.3.2 ”确定 可 替换 序列 

下 一 步 要 考虑 “验证 PIN 码 ”( Validate PIN) 用 例 的 可 替换 序列 。 在 前 一 小 节 中 描述 的 
主 序列 假设 ATM 卡片 和 PIN 码 都 是 有 效 的 。 接 下 来 ， 请 考虑 “验证 PIN 码 ” 用 例 的 不 同 的 
可 替换 用 例 ， 这 些 序列 处 理 无 效 的 卡片 以 及 错误 的 密码 等 特殊 情况 。 通 过 用 例 的 可 替换 部 分 
(第 21 章 给 出 其 完整 描述 )， 能 够 确定 这 些 可 替换 的 序列 。 

看 一 下 发 送 至 “银行 服务 ”的 “验证 PIN 码 ” 消 息 (消息 2.6 )。 从 “银行 服务 ”可 能 得 
到 多 种 不 同 的 响应 。 在 有 可 能 出 现 可 替换 序列 的 消息 排序 编号 中 ， 每 个 可 替换 序列 都 要 附加 
一 个 不 同 的 大 写字 母 来 表示 。 因 此 ， 与 消息 2.7 ( “有效 PIN 码 ”) 对 应 的 可 替换 消息 是 2.7A, 
2.7B 和 2.7C。 每 一 个 可 替换 场景 都 能 用 一 个 单独 的 交互 图 来 描绘 。 在 后 续 小 节 中 我 们 考虑 主 
场景 以 及 一 组 可 替换 场景 。 


Validating PIN 


Waiting for 
Customer Choice 


179 
2 
180 
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11.3.3 ЗЕЯ: 有 效 PIN 码 


输入 有 效 的 卡片 和 PIN 码 。 该 场景 对 应 于 主 序列 ， 并 被 赋予 了 条 件 [Valid]: 
2.7 [Valid]: 有 效 PIN 码 


在 这 种 情况 下 , “银行 服务 ”发 送 “ 有 效 PIN 码 ”( Valid PIN) 的 消息 。 主 场景 在 交互 图 
( 见 图 11-1 和 图 11-2) 和 状态 图 ( 见 图 11-3) 中 描绘 。 


11.34 可 替换 序列 : 无 效 PIN 码 


输入 一 个 无 效 的 PIN 码 。 这 个 可 替换 序列 被 赋予 了 条 件 [Invalid]: 
2.7A* [Invalid]: 无 效 PIN 码 


在 这 种 情况 下 ,“ 银 行 服务 ”发 送 “ 无 效 PIN 码 ”( Invalid PIN ) 的 消息 。 

图 11-4 在 顺序 图 上 措 绘 了 输入 无 效 PIN 码 的 可 替换 场景 。 消 息 序 列 中 的 消息 1 至 消息 2.6 
(最 先 展示 在 图 11-2 上 ) 都 没有 发 生变 化 并 且 都 被 包含 在 图 11-4 的 PIN 码 验 证 的 片段 中 。 在 无 效 
PIN 码 的 场景 中 ， 警 戒 条 件 [Invalid] 为 真 ， 这 意味 着 消息 2.7A :“ 无 效 PIN 码 ” 将 被 “银行 服务 ” 
发 送 。* 号 表示 “无 效 PIN 码 ”的 消息 可 以 被 发 送 多 次 〈 在 这 个 场景 中 ， 它 被 发 送 两 次 )。 从 消 
息 2.7A 到 消息 2.7A.11 的 和 迭代 (从 发 送 无 效 PIN 码 的 消息 到 再 次 发 送 无 效 PIN 码 消息 ) 位 于 图 
11-4 中 的 一 个 循环 片段 中 。 如 果 “ 无 效 PIN 码 ” 的 消息 被 第 二 次 发 送 ， 那么 从 2.7A 到 2.7A.11 的 
消息 序列 将 重复 发 送 。 

图 11-4 中 展示 的 场景 是 用 来 要 求 客户 第 二 次 或 第 三 次 尝试 输入 正确 的 PIN 码 数字 。 在 这 
种 情况 下 ， 从 “银行 服务 ”得 到 的 响应 是 “PIN 码 有 效 ”( PIN Valid )， 且 警戒 条 件 [Valid] 为 
真 。 图 11-4 底部 的 消息 序列 2.7 到 2.9 与 图 11-2 的 相关 部 分 一 致 。 
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Я 11-4 “验证 PIN #3” (Validate PIN ) 用 例 的 顺序 图 :“ 无 效 PIN 码 ” 的 场景 
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11.3.5 ”可 替换 序列 : 第 三 次 无 效 PIN 码 


输入 了 三 次 无 效 的 密码 ， 该 可 替换 序列 也 被 赋予 了 条 件 [Invalid]. SRT, “АТМ 客户 端 ” 
( АТМ Client ) 在 ATM 交易 的 实体 对 象 中 保存 了 已 输入 错误 密码 的 次 数 ， 并 在 运行 时 确定 该 
次 数 是 否 达 到 了 三 次 。 以 下 消息 即 表示 了 输入 三 次 无 效 PIN 码 的 场景 。 

2.7B [Third Invalid]: 第 三 次 无 效 PIN 码 

在 这 个 场景 中 , “银行 服务 ”向 “ATM 控制 ”发 送 了 三 次 “无 效 PIN 码 ”。 

第 三 次 无 效 PIN 码 的 场景 开始 于 顺序 图 ( 图 11-5 ) 中 的 PIN 码 验 证 片段 以 及 随后 的 两 
次 循环 片段 ， 每 一 个 循环 片段 均 开 始 于 由 “银行 服务 ”发 送 的 “无 效 PIN 码 ”消息 ( 消息 
2.7A )。 随 后 “ATM 控制 ”向 “ATM 交易 ”发 送 “ 更 新 状态 ”( Update Status) 消息 ( 消息 
2.7A.1 )， 得 到 一 个 表示 PIN 码 状 态 的 “无 效 PIN 码 ”( Invalid PIN ) 响应 ( 消息 2.7A.2 )， 这 个 
过 程 将 重复 两 次 。 之 后 跳出 循环 并 由 “银行 服务 ”发 送 第 三 个 2.7A :“ 无 效 PIN 码 ” 的 消息 。 
此 次 对 “更 新 状态 ”( 2.7A.1 ) 消息 的 响应 是 2.7B[Third Invalid]:“ 第 三 次 无 效 PIN 码 ”， 这 是 由 
于 第 三 次 无 效 这 一 警戒 条 件 为 真 ， 在 这 种 情况 下 卡片 就 会 被 没收 ( 消息 序列 2.7B 至 2.7B.2 )。 183 
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图 11-5 “验证 PIN #3” ( Validate PIN ) 用 例 的 顺序 图 :“ 第 三 次 无 效 PIN 码 ”的 场景 
11.3.6 ”可 替换 序列 : 被 盗 的 或 过 期 的 卡片 


卡片 被 盗 取 或 者 卡片 已 过 期 。 
2.7C [Stolen OR expired]: 卡片 被 盗 ( Сага stolen )， 卡 片 过 期 ( Card expired ) 
无 论 卡 片 是 被 盗 取 还 是 过 期 ， 消 息 序 列 都 是 一 样 的 ， 最 终 将 没收 这 张 卡 片 。 
该 可 替换 序列 在 图 11-6 的 顺序 图 中 被 描绘 。 该 图 描绘 了 ATM 卡片 过 期 或 者 已 被 挂失 时 
的 消息 序列 ( 消息 序列 2.7C 至 2.7C.2 )。 这 两 个 场景 的 处 理 方法 是 一 样 的 :“ 银 行 服务 ”将 卡 
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被 盗 取 或 卡片 过 期 的 消息 (2.720) 发 送 给 “ATM БЕН, “АТМ 控制 ”随后 发 送 一 个 “没收 卡 
片 ”( Confiscate ) 消息 (2.7C.1) 给 “卡片 读 取 接口 "， 最 后 没收 该 张 ATM 卡片 。 
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图 11-6 “验证 PIN 码 ”( Validate PIN ) 用 例 的 顺序 图 : 被 次 的 或 过 期 的 卡片 场景 
11.37 所 有 场景 通用 的 交互 图 


把 所 有 的 可 替换 场景 都 展示 在 一 张 通用 的 交互 图 ， 无 论 是 在 一 张 通用 的 通信 图 (图 11-7) 
还 是 一 张 通用 的 顺序 图 上 都 是 可 能 的 。 该 用 例 的 通用 通信 图 既 覆 盖 了 主 序列 ， 也 覆盖 了 所 有 
的 可 替换 序列 。 尽 管 在 同一 张 图 上 展示 所 有 的 可 替换 序列 会 使 对 象 交互 的 描绘 更 加 紧凑 ， 但 
是 相 比 于 独立 描绘 每 一 个 场景 ( 主场 景 或 可 替换 场景 ) 的 单个 场景 图 而 言 ， 通 用 的 图 更 难以 
阅读 。 当 且 仅 当 所 有 的 可 替换 场景 能 够 被 清晰 地 描绘 时 ， 才 应 使 用 一 个 通用 的 通信 图 或 顺序 
图 (描绘 所 有 的 可 替换 场景 )。 如 果 通 用 的 通信 图 或 顺序 图 过 于 凌乱 ， 应 当 为 每 一 个 可 替换 场 
景 使 用 单独 的 通信 图 或 顺序 图 。 


11.3.8 ”控制 对 象 和 状态 图 的 编 序 


图 11-1 到 图 11-7 中 展示 的 “ATM 控制” 对 象 执 行 了 在 图 11-8 和 11-9 中 描绘 的 状态 
图 (图 11-9 描绘 了 “验证 PIN 码 ”( Validating РМ) 复合 状态 的 子 状 态 )。 状 态 图 展示 了 
“验证 PIN 码 ” 用 例 中 主 序列 和 可 替换 序列 在 执行 过 程 中 的 不 同 状 态 。 因 此 ， 当 从 “顾客 交 
互 ” 那 里 获得 “输入 PIN 码 ” 的 事件 (事件 2.5 ) 时 , “АТМ 控制 ”将 转换 到 “验证 PIN 码 ” 
( Validating PIN ) 的 复合 状态 (“验证 PIN 码 和 卡片 ”( Validating PIN and Сага) 的 子 状态 ), 
并 向 “银行 服务 ”发 送 一 条 “验证 PIN 码 ” 的 消息 。 图 11-7 描绘 了 可 能 从 “银行 服务 ”得 到 
的 响应 。 图 11-8 和 图 11-9 展示 了 相应 的 状态 和 动作 ， 而 图 11-7 展示 了 与 被 控 对 象 间 的 交互 。 
“有 效 РІМ 码 ”( Valid PIN ) 的 响应 (事件 2.7 ) 会 导致 状态 转换 到 “等 待 客户 选择 ”( Waiting 
for Customer Choice ), “20% PIN 码 ”( Invalid PIN ) 的 响应 (事件 2.7A ) 会 导致 状态 转换 到 
“检查 PIN 码 ”( Checking PIN ) 状态 的 子 状态 (图 11-9 )。 第 二 个 “无 效 PIN 码 ” 的 响应 (Ж 
件 2.7A.1 ) 会 导致 状态 转换 回 “ 等 待 输入 PIN 码 ” 的 状态 并 且 触 发 “客户 交互 ”对 象 中 的 
“无 效 PIN 码 提示 ”( Invalid PIN Prompt ) 动作 (事件 2.7A.3 )。 第 三 个 无 效 PIN 码 (2.7B ) 的 
响应 会 导致 状态 转换 到 “没收 卡片 ”( Confiscating ) 的 状态 并 触发 “卡片 读 取 接口 ”对 象 中 的 
“没收 卡片 ”( Confiscate ) 动作 (事件 2.7B.1 )。 同 样 地 ， 对 于 一 个 “被 盗 卡片 ”的 响应 (事件 
270) 也 会 进行 相同 的 处 理 。 最 后 ， 如 果 客 户 决 定 “ 取 消 ”( Cancel ) (事件 2A.1 ) 而 不 是 重 
新 输入 PIN 码 ， 状 态 图 会 转换 到 “退出 ”( Ejecting ) 状态 ， 并 触发 “卡片 读 取 接 口 ” 对 象 中 
的 “退出 ”( Eject ) 动作 (事件 2A.2 )。 由 于 在 “ATM 控制 ”处 于 任何 子 状 态 (“等待 PIN 码 ” 
状态 、“ 验 证 PIN 码 ”状态 ， 或 “等 待 客户 选择 ”状态 ) 时 客户 都 可 以 选择 “取消 ”， 因 此 该 
状态 的 转换 被 展示 在 图 11-8 的 “处 理 客户 输入 ”( Processing Customer Input) 的 复合 状态 外 。 
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状态 图 也 启动 了 并 发 的 动作 序列 ， 它 们 在 相同 的 状态 转换 时 被 触发 。 因 此 ， 在 一 个 特定 
转换 时 发 生 的 所 有 动作 都 是 以 一 种 不 受 限 的 、 不 强制 顺序 的 方式 被 执行 。 例 如 ， 由 “验证 PIN 
码 ” 这 一 状态 转换 ( 见 图 11-8 ) 导致 的 动作 2.8“ 显 示 菜 单 ”( Display Menu ) 和 动作 2.8a“ 更 
新 状态 ”( Update Status ) 是 并 发 执行 的 ， 如 图 11-7 所 示 。 


Entry / 
Display Welcome 






1.2: Card Inserted / 
1.3: Get PIN 






2A.1: Cancel / 
2A.2: Eject, 
2А.2а: Display Cancel 








Processing 
Customer Input 













2.7А.2: Invalid PIN/ 
2.7A.3: Invalid PIN Prompt 2.7B: Third Invalid PIN / 
2.7B.1: Сопћзса! 












2.7C: Card Stolen, Card Expired / 
2.7С.1: Confiscate, 
2.7C.1a: Update Status 


Waiting for 
Customer Choice 


РА 11-8 “验证 PIN #3” FAB “АТМ 控制 ”的 状态 图 ， 展 示 了 可 替换 场景 










Waiting for 
PIN 


2.5, 2,7A.10: PIN Entered / 
2.6, 2,7A.11: Validate PIN 


2.7A.2: Invalid PIN / 
2.7A.3: Invalid PIN Prompt 


Validating 
PIN 
2.7A: Invalid PIN / 
Validating PIN | 2.7A.1 Update Status {Checking PIN 
and Card Status 


2.7[Valid]: Valid PIN / 
2.8: Display Menu, 
2.8а: Update Status 






2.7B: Third Invalid PIN / 
2.78.1: Confiscate 


Confiscating 






2.7C: Card Stolen, Card Expired / 
2.7С.1: Confiscate, 
2.7С.1а; Update Status 












Waiting for 
Customer 


Н 11-9 “ATM 控制 ”中 “验证 PIN 码 ” 复 合 状态 的 状态 图 


11.4 总 结 


本 章 描述 了 状态 相关 的 交互 建 模 ， 其 中 的 对 象 交 互 是 状态 相关 的 。 一 个 状态 相关 的 交互 
涉及 了 至 少 一 个 状态 相关 的 控制 对 象 ， 该 控制 对 象 执行 一 个 提供 全 局 控制 与 交互 编 序 的 状态 
图 ( 见 第 10 章 )。 本 章 建 立 在 第 9 章 描 述 的 无 状态 动态 交互 建 模 之 上 ， 无 状态 的 动态 交互 建 
模 不 涉及 任何 状态 相关 的 交互 。 
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练习 


选择 题 ( 每 道 题 选择 一 个 答案 ) 

1. 状态 相关 的 交互 涉及 什么 ? 

(а) 一 个 控制 对 象 

(b) 一 个 状态 相关 的 实体 对 象 

(с) 一 个 状态 相关 的 控制 对 象 

(а) 一 个 状态 相关 的 用 户 接口 对 象 

. 以 下 哪 种 对 象 会 执行 状态 机 ? 

Ca) 任何 的 软件 对 象 

(b) 一 个 实体 对 象 

(с) 一 个 状态 相关 的 控制 对 象 

(а) 一 个 状态 图 

. 向 状态 相关 的 控制 对 象 发 送 的 一 条 输入 消息 对 应 于 以 下 哪 一 项 ? 
(a) 内 部 状态 机 上 的 一 个 事件 

(b) 内 部 状态 机 上 的 一 个 动作 

(с) 内 部 状态 机 上 的 一 个 条 件 

(d) 内 部 状态 机 上 的 一 个 状态 

.从 状态 相关 的 控制 对 象 发 送 的 一 条 输出 消息 对 应 于 以 下 哪 一 项 ? 
(a) 内 部 状态 机 上 的 一 个 事件 

(b) 内 部 状态 机 上 的 一 个 动作 

(с) 内 部 状态 机 上 的 一 个 条 件 

(4) 内 部 状态 机 上 的 一 个 状态 

. 交互 图 应 为 以 下 哪 一 项 开发 ? 

(а) 仅 用 例 的 主 序列 

(b) 用 例 的 主 序列 和 每 一 个 可 替换 序列 

(с) 用 例 的 主 序列 和 一 个 具有 代表 性 的 可 替换 序列 

(а) 用 例 的 所 有 可 替换 序列 

， 下 列 哪 一 项 可 能 发 生 在 一 个 交互 图 上 ? 

(а) 一 个 状态 相关 的 控制 对 象 向 一 个 实体 对 象 发 送 一 条 消息 
(b) 一 个 状态 相关 的 控制 对 象 向 一 个 协调 者 对 象 发 送 一 条 消息 
(с) 一 个 状态 相关 的 控制 对 象 向 一 个 打印 机 对 象 发 送 一 条 消息 
(d) 以 上 所 有 

如 果 多 个 用 例 使 用 同一 个 状态 机 ， 这 种 情况 应 当 怎样 在 交互 图 上 建 模 ? 
(а) 为 每 一 个 用 例 开发 一 个 状态 相关 的 控制 对 象 

(b) 开发 一 个 状态 相关 的 控制 对 象 ， 该 对 象 包含 来 源 于 每 一 个 用 例 的 状态 
(c) 开发 一 个 层次 化 的 状态 图 

(4) 开发 一 个 协调 者 对 象 

. 两 个 状态 相关 的 控制 对 象 间 是 怎样 互相 通信 的 ? 

(a) 通过 相互 发 送 消息 
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(b ) 通过 转换 到 相同 的 状态 上 
(c) 通过 一 个 实体 对 象 
(d) 通过 一 个 代理 对 象 
9. 一 个 对 象 可 以 向 一 个 状态 相关 的 控制 对 象 发 送 两 个 可 替换 消息 а 或 b。 状 态 机 如 何 处 理 这 
种 情况 ? 
(а) 对 每 一 个 进入 的 消息 定义 一 个 具有 不 同 转换 的 状态 
Cb) 对 每 一 个 可 替换 消息 定义 一 个 状态 
(с) 定义 一 个 组 合 状态 来 处 理 可 替换 消息 
188 (а) 对 每 一 个 可 替换 消息 定义 一 个 子 状 态 
10. 在 一 个 客户 端 对 象 执行 一 个 状态 机 并 且 与 服务 进行 通信 的 系统 中 ， 下 列 哪 项 陈述 是 正 
确 的 ? 
(а) 客户 端 拥 有 一 个 状态 相关 的 控制 对 象 ， 但 是 服务 没有 
(b ) 服务 拥有 一 个 状态 相关 的 控制 对 象 ， 但 是 客户 端 没 有 
(с) 客户 端 和 服务 都 拥有 状态 相关 的 控制 对 象 
190 (4) 客户 端 和 服务 都 没有 状态 相关 的 控制 对 象 


| 第 三 部 分 


Software Modeling & Design: UML, Use Cases, Patterns, & Software Architectures 


软件 体系 结构 设计 


第 12 章 | 


Software Modeling & Design: UML, Use Cases, Patterns, & Software Architectures 


软件 体系 结构 概览 





软件 体系 结构 按照 子 系统 及 其 接口 的 形式 将 系统 的 总 体 结构 与 单个 子 系统 的 内 部 细节 相 
分 离 。 软 件 体系 结构 由 相对 独立 的 子 系统 构成 。 本 章 将 对 软件 体系 结构 ( 也 被 称 为 一 种 高 层 
设计 ) 进行 概要 性 的 介绍 。 其 中 ， 关 于 软件 体系 结构 以 及 体系 结构 的 多 视图 的 概念 已 经 在 第 
1 章 中 介绍 过 。 关 于 设计 模式 、 构 件 以 及 接口 的 概念 则 在 第 4 章 中 介绍 过 。 

在 本 章 中 ，12.1 节 介 绍 了 软件 体系 结构 以 及 基于 构件 的 软件 体系 结构 的 概念 。 接 着 ， 
12.2 节 描 述 了 如 何 通 过 软件 体系 结构 的 多 视图 来 更 好 地 进行 设计 和 理解 体系 结构 。12.3 节 中 
介绍 作为 软件 体系 结构 开发 的 基础 的 软件 体系 结构 模式 的 概念 。12.4 节 则 描述 了 如 何 描述 这 
些 模式 。12.5 节 介 绍 软件 构件 和 接口 的 概念 。 最 后 ，12.6 节 提 供 一 个 软件 体系 结构 设计 的 总 
体 概览 ， 涵 盖 了 从 第 14 章 到 第 20 章 的 内 容 。 


12.1 软件 体系 结构 以 及 基于 构件 的 软件 体系 结构 


Bass, Clements, and Kazman ( 2003 ) 所 给 出 的 软件 体系 结构 的 定义 如 下 : 
“一 个 程序 或 者 计算 系统 的 软件 体系 结构 是 包含 了 该 系统 的 软件 元 素 、 这 些 元 
素 的 外 部 可 见 的 属性 以 及 这 些 元 素 之 间 关 系 的 结构 或 一 组 系统 结构 。” 
因此 ， 软 件 体系 结构 主要 是 从 结构 方面 考虑 的 。 然 而 ， 为 了 充分 理解 一 个 软件 体系 结构 ， 
有 必要 从 多 个 不 同 角度 考虑 软件 体系 结构 ， 包 括 静 态 方面 和 动态 方面 ， 如 12.2 节 所 描述 。 同 
时 ， 还 有 必要 从 功能 性 ( 体系 结构 所 提供 的 功能 ) 和 非 功 能 性 ( 所 提供 的 功能 的 质量 ) 两 个 
方面 进行 考虑 。 体 系 结构 的 软件 质量 属性 会 在 第 20 章 中 进行 介绍 。 


12.1.1 基于 构件 的 软件 体系 结构 


软件 体系 结构 的 结构 方面 可 以 通过 得 到 广泛 接受 的 基于 构件 的 软件 体系 结构 的 思想 来 考 
虑 。 一 个 基于 构件 的 软件 体系 结构 由 多 个 构件 组 成 ， 其 中 每 个 构件 相互 独立 且 封 装 了 某 些 信 
息 。 一 个 构件 可 以 是 一 个 由 其 他 对 象 组 成 的 复合 对 象 ， 也 可 以 是 一 个 简单 对 象 。 构 件 通 过 接 
口 与 其 他 构件 进行 通信 。 所 有 与 其 他 构件 进行 通信 所 需要 的 信息 都 包含 在 接口 之 中 ， 并 且 接 
口 与 实现 相 分 离 。 因 此 ， 构 件 可 以 被 认为 是 一 个 黑 盒 ， 因 为 它 的 实现 对 于 其 他 构件 而 言 是 不 
可 见 的 。 构 件 之 间 使 用 预先 定义 好 的 通信 模式 以 不 同 的 方式 进行 通信 。 

顺序 式 设计 是 指 程序 中 的 构件 是 一 个 个 的 类 ， 而 构件 的 实例 是 对 象 ( 也 就 是 类 的 实例 ) ; 
这 些 构件 是 没有 控制 线程 的 被 动 类 。 一 个 构件 是 相对 独立 的 ， 因 此 可 以 单独 进行 编译 并 存储 
在 构件 库 中 ， 然 后 被 实例 化 并 链接 到 一 个 应 用 中 。 在 顺序 式 设 计 中 ， 唯 一 的 通信 模式 是 调用 / 
返回 ， 将 在 12.3.2 节 中 进行 介绍 。 

在 并 发 或 者 分 布 式 设计 中 ,构件 是 主动 的 (并 发 的 )， 并且 能 够 被 部 署 到 一 个 分 布 式 环 
境 中 的 不 同 结 点 上 。 在 这 类 设计 中 ， 并 发 构件 之 间 可 以 通过 几 种 不 同 的 通信 模式 来 进行 通信 
(№, 12.3 节 )， 例 如 同步 模式 、 异 步 模式 、 代 理 模 式 或 群 组 通信 模式 ， 并 且 通 常 都 会 使 用 一 种 
底层 的 中 间 件 框架 以 允许 构件 之 间 进 行 通信 。 
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12.1.2 ”体系 结构 构造 型 


在 UML 2 中 ， 一 个 建 模 元 素 可 以 使 用 多 个 构造 型 进行 描述 。 在 分 析 建 模 时 ， 构 造型 可 
以 用 于 表示 一 个 建 模 元 素 ( 类 或 对 象 ) 的 角色 特性 。 在 设计 建 模 时 ， 其 他 构造 型 可 以 用 于 表 
示 一 个 建 模 元 素 的 体系 结构 特性 。 这 一 能 力 非常 有 用 ， 而 COMET 方法 也 充分 利用 了 这 一 点 。 
特别 地 ， 可 以 用 一 种 构造 型 来 描述 建 模 元 素 所 扮演 的 角色 ， 如 是 否 是 边界 类 或 是 实体 类 。 而 
另 一 种 构造 型 可 以 用 来 在 设计 建 模 时 表示 体系 结构 的 结构 元 素 ， 如 子 系统 (第 12 章 )、 构 件 
(第 17 章 )、 服 务 (第 16 章 ) 或 者 并 发 任务 (第 18 章 )。 必 须 注 意 ， 对 于 一 个 给 定 的 类 ， 它 
的 角色 构造 型 和 体系 结构 的 结构 构造 型 是 正 交 的 ， 即 是 相互 独立 的 。 


12.2 ”软件 体系 结构 的 多 视图 


软件 体系 结构 设计 可 以 从 不 同 视角 ( 称 为 体系 结构 视图 ) 进行 描述 。 软 件 体系 结构 的 结 
构 视 图 可 以 用 类 图 来 描述 ， 如 12.2.1 节 所 述 。 软 件 体 系 结构 的 动态 视图 可 以 用 通信 图 来 描述 ， 
如 12.2.2 节 所 述 。 软 件 体系 结构 的 部 署 视图 可 以 用 部 署 图 来 描述 ， 如 12.2.3 节 所 述 。 还 有 一 
种 体系 结构 视图 ， 即 基于 构件 的 软件 体系 结构 视图 ， 将 在 第 17 章 中 进行 介绍 。 


12.2.1 软件 体系 结构 的 结构 视图 


软件 体系 结构 的 结构 视图 是 一 种 静态 视图 ， 不 会 随 着 时 间 而 发 生 改 变 。 在 视图 的 最 高 层 ， 
相应 的 子 系统 使 用 类 图 来 进行 描述 。 其 中 ， 一 个 子 系统 类 图 通过 复合 类 或 聚合 类 描述 子 系统 
之 间 的 静态 结构 关系 以 及 它们 之 间 关 联 关系 的 重 数 。 

作为 软件 体系 结构 结构 视图 的 一 个 例子 ， 可 以 考虑 一 个 包含 多 个 客户 端 和 一 个 服务 器 的 
客户 端 / 服 务 器 软件 体系 结构 的 设计 。 这 种 体系 结构 的 一 个 例子 是 “银行 系统 ”， 其 中 有 多 个 
“ATM 客户 端 ”( ATM Client) 子 系统 的 实例 以 及 一 个 “银行 服务 ”( Banking Service) 子 系统 
的 实例 。 图 12-1 展示 了 该 体系 结构 的 静态 视图 ， 其 中 客户 端 和 服务 子 系统 都 描述 在 一 个 类 图 
Е. М 12-1 描绘 了 银行 系统 中 “银行 服务 ”和 “ATM 客户 端 ” 之 间 的 静态 关系 ， 其 中 包括 
“ATM 客户 端 ” 与 “银行 服务 ”之 间 “ 请 求 服 务 ” 的 关联 关系 的 名 称 和 方向 以 及 该 关联 关系 
的 重 数 ， 即 服务 和 客户 端 之 间 的 一 对 多 关联 。 此 外 ， 客 户 端 和 服务 子 系统 ( 在 图 12-1 PAR 
合 类 描绘 ) 都 使 用 了 两 个 构造 型 来 描述 ， 其 中 第 一 个 表示 角色 构造 型 ( 客户 端 或 者 服务 )， 而 
第 二 个 则 表示 体系 结构 的 结构 构造 型 ( 在 本 例 中 都 是 子 系统 )。 


12.22 ”软件 体系 结构 的 动态 视图 


软件 体系 结构 的 动态 视图 是 一 种 行为 视图 ， 可 以 用 通信 图 来 表示 。 一 个 子 系统 通信 图 描 
述 了 子 系统 ( 用 聚合 对 象 或 者 复合 对 象 描述 ) 以 及 子 系统 之 间 的 消息 通信 。 这 些 子 系统 可 以 
被 部 署 到 不 同 的 结 点 上 ， 因 此 被 描述 成 并 发 的 构件 ， 因 为 它们 可 以 并 行 执 行 并 在 一 个 网 络 上 
进行 相互 通信 。 

图 12-2 中 的 子 系统 通信 图 描述 了 “银行 系统 ”客户 端 / 服 务 器 软件 体系 结构 的 动态 视 
图 。 图 中 描述 了 “银行 系统 ”的 两 个 子 系统 : 拥有 多 个 实例 的 “ATM 客户 端 ” 子 系统 和 只 
有 单个 实例 的 “银行 服务 ” 子 系统 。 每 一 个 “ATM 客户 端 ” 都 会 向 “银行 服务 ”发 送 交 易 
请 求 并 接收 应 答 。 “АТМ 客户 端 ” 和 “银行 服务 ”都 被 描述 为 并 发 的 构件 ， 因 为 二 者 相互 
并 行 执行 ， 虽 然 有 时 候 它们 之 间 需 要 进行 通信 。 因 此 ， 当 一 个 客户 端正 准备 向 服务 器 发 送 
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一 个 请 求 时 ,“ 银 行 服务 ”可 能 正在 为 另 一 个 客户 端 提 供 服 务 。 当 服务 正在 处 理 某 个 客户 端 
的 请 求 时 ， 该 客户 端 通常 会 等 待 服务 的 答复 。 这 种 类 型 的 通信 ( 即 包含 回复 的 同步 消息 通 
信 ) 将 在 12.3.4 节 中 详细 介绍 。 在 UML 通信 图 (如 图 12-2) 中 ， 同 步 消 息 (АТМ 交易 ， 
ATMTransaction) 用 黑色 箭头 表示 ， 而 回复 信息 (银行 回复 ，bankResponse ) 用 虚线 箭头 表 
示 。 另 一 种 同步 通信 的 表示 法 将 在 12.3.4 节 中 描述 并 且 在 图 12-11 中 展示 。 
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图 12-1 客户 端 /服务 器 软件 体系 结构 的 结构 视图 :“ 银 行 系统 ”的 高 层 类 图 
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196 图 12-2 ”客户 端 / 服 务 器 软件 体系 结构 的 动态 视图 :“ 银 行 系统 ”的 高 层 通信 图 


子 系统 通信 图 是 一 种 泛 化 的 通信 图 ， 因 为 它 描 述 了 对 象 之 间 所 有 可 能 的 交互 ( 见 9.1.5 
节 )。 由 于 其 描述 了 所 有 可 能 的 交互 场景 ， 因 此 没有 使 用 消息 顺序 编号 。 此 外 ， 由 于 泛 化 的 通 
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信 图 描述 了 泛 化 的 实例 (这 意味 着 它们 描述 了 潜在 的 实例 而 不 是 真实 的 实例 )， 因 此 这 里 使 用 
了 不 在 对 象 名 称 下 使 用 下 划 线 的 UML 2 惯例 。 

除了 泛 化 之 外 ， 子 系统 通信 图 也 是 并 发 的 ， 因 为 它 描述 的 是 并 发 执行 的 对 象 ( 见 2.8 17 
中 的 UML 表示 法 描述 )。 因 此 ， 图 12-2 描述 了 两 个 在 位 置 上 分 布 的 并 发 子 系统 ， 即 “ATM 
客户 端 ” 和 “银行 服务 "。 


12.2.3 ”软件 体系 结构 的 部 署 视图 


软件 体系 结构 的 部 署 视图 描述 了 软件 体系 结构 的 物理 配置 ， 特 别 是 体系 结构 中 的 子 系统 
是 如 何在 一 个 分 布 的 配置 中 分 配 到 不 同 的 结 点 上 。 一 个 部 署 图 可 以 描述 具有 固定 数量 的 结 点 
的 特定 部 署 。 此 外 ， 部 署 图 也 可 以 描述 部 署 的 总 体 结构 ， 例 如 指明 一 个 子 系统 可 以 拥有 多 个 
实例 且 每 个 实例 都 可 以 部 署 到 一 个 单独 的 结 点 上 ， 但 是 并 没有 描述 实例 的 确切 数量 。 图 12-3 
描述 了 “银行 系统 ”客户 端 / 服务 器 软件 体系 结构 的 部 署 视图 ， 在 该 部 署 中 ， 每 一 个 ATM 客 
户 端 实例 都 被 分 配 到 它 自 己 的 物理 结 点 上 ， 而 集中 式 的 银行 服务 则 被 分 配 到 一 个 单独 的 结 点 
上 。 此 外 ， 所 有 的 结 点 都 是 通过 广域网 进行 连接 的 。 
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图 12-3 客户 端 /服务 器 软件 体系 结构 的 部 署 视图 :“ 银 行 系统 ”的 部 署 图 












12.3 ”软件 体系 结构 模式 


第 4 章 介绍 了 软件 模式 的 概念 以 及 不 同 的 模式 ， 包 括 软件 体系 结构 模式 和 软件 设计 模式 。 
软件 体系 结构 模式 为 应 用 的 总 体 软件 体系 结构 或 者 高 层 设 计 提 供 了 一 种 骨架 或 者 模板 。Shaw 
and Garlan ( 1996 ) 将 其 称 为 体系 结构 风格 或 体系 结构 模式 ， 即 在 不 同 的 软件 应 用 中 重复 出 现 
的 体系 结构 (JL Bass, Clements, and Kazman 2003 )。 这 其 中 包括 了 被 广泛 使 用 的 客户 端 / 服 
务 器 体系 结构 和 分 层 体系 结构 。 

软件 体系 结构 模式 可 以 被 分 成 两 大 类 : 表示 体系 结构 静态 结构 的 体系 结构 结构 模式 和 表 
示 体 系 结构 的 构件 间 的 分 布 式 动态 通信 的 体系 结构 通信 模式 。 本 章 介绍 软件 体系 结构 模式 的 
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概念 以 及 一 种 体系 结构 结构 模式 ， 即 抽象 分 层 模式 (12.3.1 节 )， 此 外 还 介绍 了 三 种 体系 结构 
通信 模式 ， 分 别 是 调用 /返回 模式 (12.3.2 节 )、 异 步 消息 通信 模式 (12.3.3 节 ) 以 及 带 回复 
的 同步 消息 通信 模式 (12.3.4 节 )， 其 他 模式 将 会 在 之 后 的 章节 中 进行 介绍 。 表 12-1, 12-2 和 
12-3 介绍 了 各 种 模式 的 章节 位 置 。 


Ж 12-1 软件 体系 结构 结构 模式 


软件 体系 结构 结构 模式 = т 
集中 式 控制 模式 第 18 章 ，18.3.1 节 
分 布 式 控制 模式 第 18 章 ，18.3.2 节 
层次 化 控制 模式 第 18 章 ，18.3.3 节 
抽象 分 层 模式 第 12 章 ，12.3.1 节 
多 客户 端 / 多 服务 模式 第 15 章 ，15.2.2 节 
多 客户 端 / 单 服务 模式 第 15 章 ，15.2.1 节 
多 层次 客户 端 / 服务 模式 第 15 章 ，15.2.3 节 


表 12-2 软件 体系 结构 通信 模式 


软件 体系 结构 通信 模式 = + 

异步 消息 通信 模式 第 12 章 ，12.3.3 节 

带 回 调 的 异步 消息 通信 模式 第 15 章 ，15.3.2 节 
双向 异步 消息 通信 第 12 章 ，12.3.3 节 
广播 模式 第 17 章 ，17.6.1 节 
代理 者 转发 模式 第 16 章 ，16.2.2 节 
代理 者 句柄 模式 第 16 章 ，16.2.3 节 
调用 /返回 模式 第 12 章 ，12.3.2 节 
协商 模式 第 16 章 ，16.5 节 
服务 发 现 模式 第 16 章 ，16.2.4 节 
服务 注册 模式 第 16 章 ，16.2.1 节 
订阅 /通知 模式 第 17 章 ，17.6.2 节 

带 回复 的 同步 消息 通信 模式 第 12 章 ，12.3.4 节 ; 第 15 章 ，15.3.1 节 
不 带 回复 的 同步 消息 通信 模式 第 18 章 ，18.8.3 节 


12-3 ”软件 体系 结构 事务 模式 





软件 体系 结构 事务 模式 Е + 
复合 事务 模式 第 16 章 ，16.4.2 17 
长 事务 模式 第 16 章 ，16.4.3 节 
两 阶段 提交 协议 模式 第 16 章 ，16.4.1 节 


12.3.1 抽象 分 层 体系 结构 模式 


抽象 分 层 模式 ( 也 被 称 为 层次 结构 或 抽象 层次 模式 ) 是 一 种 被 广泛 应 用 于 许多 不 同 的 软 
件 领 域 的 体系 结构 模式 (BuSchmann et al. 1996 )。 操 作 系 统 、 数 据 库 管理 系统 以 及 网 络 通信 
软件 都 是 经 常 使 用 层次 结构 的 软件 系统 的 例子 。 
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WLR Parnas (1979) 在 他 关于 软件 设计 易于 扩展 和 收缩 的 那 篇 开创 性 论文 中 所 指出 的 
那样 ( 参见 Hoffman and Weiss 2001 )， 如 果 软 件 是 按照 层次 的 形式 设计 的 ， 那 么 该 软件 可 
以 通过 添加 使 用 较 低层 次 上 所 提供 的 服务 的 上 层 来 进行 扩张 或 者 通过 移 除 上 层 来 进行 收缩 。 

在 一 个 严格 的 层次 中 ， 每 一 层 只 能 调用 紧邻 的 下 
一 层 所 提供 的 服务 ( 例如 第 3 层 只 能 调用 第 2 层 所 提 
供 的 服务 )。 在 一 个 灵活 的 层次 中 ， 每 一 层 不 仅 能 够 
调用 紧邻 的 下 一 层 的 服务 ， 而 且 还 能 调用 其 更 下 层 的 
服务 〈 例 如 第 3 层 可 以 调用 由 第 1 层 所 提供 的 服务 )。 

作为 互联 网 上 使 用 最 广泛 的 协议 ，TCP/P 协议 
就 使 用 了 抽象 分 层 的 体系 结构 模式 (Comer 2008 )。 
该 协议 中 的 每 一 层 都 负责 处 理 网 络 通信 中 的 某 些 特定 
任务 ， 同 时 以 操作 集合 的 形式 为 该 层 之 上 的 其 他 层 提 
供 接 口 。 发 送 结 点 中 的 每 一 层 在 接收 结 点 上 都 有 一 层 
与 之 相对 应 。TCP/IP 协议 共 包含 以 下 五 个 概念 层 〈 如 
图 12-4 所 示 )。 

第 1 层 : 物理 层 。 对 应 基础 的 网 络 硬件 ， 包 括 电 














气 和 机 械 接口 以 及 物理 传输 媒介 。 
第 2 层 : 网 络 接口 层 。 明 确 了 数据 是 如 何 组 织 成 ” 图 12-4 抽象 分 层 体系 结构 模式 : 互联 
帧 以 及 帧 是 如 何在 网 络 上 进行 传输 的 。 М (TCP/IP ) 参考 模型 示例 


第 3 层 : 互联 网 层 。 也 被 称 作 互 联网 协议 (IP ) 层 。 这 一 层 明 确 了 在 互联 网 上 发 送 的 数 
据 包 的 格式 ， 以 及 通过 一 个 或 多 个 路 由 器 将 数据 包 从 一 个 源头 转发 到 一 个 目的 地 的 机 制 〈 见 
图 12-5 )。 图 12-5 中 的 路 由 器 结 点 是 一 个 连接 局 域 网 和 广域网 的 网 关 。 








图 12-5 ”抽象 分 层 体系 结构 模式 通过 TCP/IP 的 互联 网 通信 
第 4 层 : 传输 层 (TCP )。 这 一 层 将 包 按 照 它们 发 送 时 的 原始 顺序 重组 成 消息 。 传 输 控制 
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协议 也 称 为 TCP， 使 用 ІР 网 络 协议 来 传达 信息 。 它 提供 了 一 个 从 一 个 结 点 上 的 应 用 到 另 一 个 
远程 结 点 上 的 应 用 之 间 的 虚拟 连接 ， 因 此 提供 了 一 种 所 谓 的 端 到 端 协议 〈《 见 图 12-5 )。 

第 5 层 : 应 用 层 。 支 持 各 种 不 同 的 网 络 应 用 ， 如 文件 传输 (FTP )、 电 子 邮 件 以 及 万 维 网 
( World Wide Web, WWW )。 

层次 体系 结构 的 一 个 有 趣 的 特性 是 可 以 直接 将 一 个 较 高 的 层 蔡 换 为 使 用 较 低 层 上 所 提 
供 的 相同 服务 的 其 他 层 。 另 一 个 有 趣 的 特性 在 图 12-5 中 进行 了 展示 。 路 由 器 结 点 只 使 用 了 
TCP/IP 协议 中 底下 的 三 层 ， 而 应 用 结 点 把 五 层 都 使 用 了 。 

一 个 严格 的 层次 软件 体系 结构 的 例子 是 本 书 中 “在 线 购物 系统 ”的 示例 ， 在 第 22 ЕН 
介绍 并 且 也 在 图 12-6 中 进行 了 描述 。 该 层次 中 最 底层 的 是 服务 层 ， 提 供 上 层 所 需要 的 服务 。 
最 顶层 是 用 户 层 ， 由 用 户 交 互 对 象 组 成 。 中 间 层 是 一 个 协调 层 ， 协 调用 户 的 请 求 至 相应 的 
服务 。 


12.3.2 调用 /返回 模式 


对 象 之 间 最 简单 的 通信 形式 是 使 用 调用 / 返回 模式 。 一 个 顺序 设计 由 被 动 类 组 成 ， 这 些 
被 动 类 被 实例 化 为 被 动 对 象 。 在 顺序 设计 中 ， 对 象 之 间 唯 一 的 通信 形式 是 操作 (也 被 称 为 方 
法 ) 调用 ， 也 就 是 所 谓 的 调用 /返回 模式 。 在 这 个 模式 中 ， 一 个 调用 对 象 的 调用 操作 去 调用 
被 调用 对 象 的 被 调用 操作 ， 如 图 12-7a 所 示 。 当 操作 被 调用 的 时 候 ， 控 制 从 调用 操作 传递 到 
被 调用 操作 。 当 控制 发 生 传递 时 ， 所 有 输入 参数 都 从 调用 操作 传递 到 被 调用 操作 。 被 调用 操 
作 执 行 完 毕 后 会 将 控制 以 及 所 有 输出 参数 返回 给 调用 操作 。 如 图 12-7a 的 UML 通信 图 所 示 ， 
调用 /返回 模式 使 用 UML 表示 法 来 表示 同步 通信 (黑色 箭头 )。 

作为 一 个 调用 /返回 模式 的 例子 ， 考 虑 包含 关于 支票 账户 和 储蓄 账户 类 的 实例 的 顺序 设计 
的 例子 ( 见 图 12-7b )。 在 这 个 例子 中 ， 每 一 个 对 象 都 提供 “ 记 入 贷方 ”( credit ) 和 “ 记 入 借方 ” 
(debit) 的 操作 ， 这 些 操作 可 以 被 “取款 交易 管理 器 ”对 象 或 者 “转账 交易 管理 器 ”对 象 调用 。 
“取款 交易 管理 器 ”通过 包含 “账户 号 ”( account#f ) 和 取款 “金额 ”( amount ) 的 输入 参数 来 调 
用 任意 一 种 账户 对 象 的 “ 记 和 人 贷方”( credit ) 操作 。 该 操作 被 调用 时 ， 另 一 个 被 称 为 “ 读 取 余 
额 ”( readBalance ) 的 操作 会 在 取款 之 后 返回 账户 所 剩 的 余额 。 为 了 处 理 一 个 转账 请 求 ,“ 转 账 
交易 管理 器 ”会 调用 一 个 账户 的 “ 记 入 借方 ”( debit ) 操作 (以 “账户 号 ”和 借方 “金额 ”作为 
BR) 以 及 另 一 个 账户 的 “ 记 和 贷方 ”( credit ) 操作 (以 “账户 号 ”和 贷方 “金额 ”作为 参数 )。 


12.33 ”异步 消息 通信 模式 


并 发 和 分 布 式 的 设计 中 还 可 以 使 用 其 他 的 通信 方式 。 通 过 异步 (也 被 称 作 松 耦 合 ) 消息 
通信 模式 ， 生 产 者 构件 发 送 一 条 消息 给 消费 者 构件 〈 见 图 12-8) 并 且 不 等 待 其 回复 。 生 产 者 
会 继续 执行 ， 因 为 它 要 么 并 不 需要 一 个 回复 ， 要 么 在 收 到 回复 之 前 还 要 执行 一 些 其 他 的 功能 。 
消费 者 收 到 所 发 出 的 消息 ; 如 果 消 费 者 正在 处 理 其 他 事情 ， 那 么 该 消息 会 进入 等 待 队 列 。 由 
于 生产 者 和 消费 者 构件 是 异步 执行 的 ( 即 处 理 速 度 不 同 )， 因 此 可 以 在 生产 者 和 消费 者 之 间 建 
立 一 个 先进 先 出 ( FIFO ) 的 消息 队列 。 当 消费 者 请 求 消息 但 消息 却 没 有 到 达 时 ， 该 消费 者 会 
被 挂 起 。 当 消息 到 达 后 ， 消 费 者 会 被 唤醒 继续 工作 。 在 分 布 式 的 环境 中 ,任何 可 能 会 提高 灵 
活性 的 地 方 都 可 能 使 用 异步 消息 通信 模式 。 该 方法 也 可 以 用 在 发 送 者 不 需要 接收 者 进行 回复 
的 情况 下 。 
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callingObject 


| invokeOperation(in inputParameter, 


out outputParameter) 
calledObject 


а) 调用 /返回 模式 


















: Withdrawal 
Transaction 
Manager 






: Transfer 
Transaction 
Manager 


















debit(account#, 
amount), 
credit(account#, debit(account#, 
amount), Ра / amount), 
readBalance credit(account#, 
amount), 
readBalance 






уча 





debit(account#, debit(account#, 
amount), amount), | 
: Checking | credit(account#, credit(accounté#, : Savings 
Account amount), ить Account 
readBalance В 





b) 调用 /返回 模式 示例 
Е 12-7 调用 /返回 模式 


图 12-8 是 一 个 UML 实例 通信 图 ， 图 中 展示 了 一 个 生产 者 向 消费 者 发 送 异 步 消 息 的 特定 
场景 。 在 如 图 12-8 所 示 的 UML 通信 图 中 ， 异 步 消 息 通 信 模 式 使 用 UML 表示 法 来 表示 异步 


消息 ( 棍 状 箭头 )。 
ЕЧ 


1: sendAsynchronousMessage (іп message) 
[== 
12-8 异步 消息 通信 模式 

图 12-9 中 的 泛 化 通信 图 描述 了 一 个 分 布 式 环境 下 的 异步 消息 通信 模式 的 例子 。 图 中 所 描 
述 的 “自动 引导 车 辆 系统 ”中 所 有 构件 之 间 的 通信 都 是 异步 的 。 在 该 系统 中 ,“ 系 统 监督 代理 
器 ”( SupervisorySystem Proxy ) 和 “抵达 传感器 构件 ”( ArrivalSensorComponent ) 都 向 车 载 控 
制 器 (VehicleControl ) 发 送 异 步 消息 ， 这 些 消息 放 在 先进 先 出 队列 中 。“ 车 辆 控制 ”( Vehicle 
Control ) 有 一 个 输入 消息 队列 ， 可 从 中 接收 首先 到 达 的 信息 : 移动 信息 或 者 抵达 信息 。 


: SupervisorySystem : ArrivalSensor 
Proxy Component 
— 


arriving (station#) 
moveToStation 


(station#) 


: VehicleControl 


12-9 异步 消息 通信 模式 示例 : 自动 引导 和 车辆 系统 
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两 个 构件 之 间 也 可 以 使 用 点 对 点 的 异步 消息 通信 。 这 类 通信 被 称 为 双向 异步 通信 ， 如 
图 12-10 所 示 。 关 于 双向 异步 通信 的 例子 在 16 章 和 18 章 中 给 出 。 


aProducer aConsumer 


12.3.4” 带 回复 的 同步 消息 通信 模式 


在 带 回 复 的 同步 (ЖК RRA) 消息 通信 模式 中 ， 客 户 端 构件 向 服务 构件 发 送 一 条 
消息 并 且 等 待 服务 构件 的 回复 ( 见 图 12-11 )。 当 所 发 送 的 消息 到 达 服 务 构件 时 ， 服 务 构件 会 
接收 该 消息 并 进行 处 理 ， 然 后 生成 一 个 回复 并 将 回复 发 送 回 客户 端 。 之 后 客户 端 和 服务 构件 
都 继续 做 各 自 的 事情 。 当 没有 收 到 任何 消息 时 ， 服 务 构件 会 挂 起 。 虽 然 完 全 可 以 只 有 一 个 客 
户 端 和 一 个 服务 ,但 同步 消息 通信 一 般 都 会 包含 多 个 客户 端 和 一 个 服务 。 由 于 这 种 模式 是 基 
于 客户 端 /服务 器 体系 结构 的 ， 因 此 第 15 章 会 对 其 进行 更 详细 的 介绍 。 

12-11 是 一 个 描述 了 特定 场景 的 UML 实例 通信 图 。 在 该 场景 中 ， 一 个 生产 者 向 一 个 消 
费 者 发 送 了 一 条 同步 消息 并 且 从 消费 者 那里 接收 回复 。 在 像 图 12-11 这 样 的 UML 通信 图 中 ， 
同步 消息 通信 模式 使 用 UML 表示 法 来 表示 带 回 复 的 同步 消息 通信 ( 黑色 箭头 )， 向 外 发 出 的 
请 求 是 输入 参数 message， 而 回复 就 是 输出 参数 response。 


1: sendSynchronousMessagewithReply 
(in message, out response) 
一 一 一 一 
aClient aService 


图 12-11 带 回 复 的 同步 信息 通信 模式 


1: sendAsynchronousMessage (in message) 
一 一 > 


=—— 
2: sendAsynchronousResponse (in response) 


Н 12-10 ”双向 异步 消息 通信 模式 

















124 描述 软件 体系 结构 模式 


无 论 何 种 类 型 的 模式 ， 使 用 一 种 标准 的 方式 来 描述 和 记录 模式 都 是 非常 有 用 的 ， 可 以 使 
模式 更 容易 被 提 及 和 引用 、 与 其 他 模式 进行 比较 以 及 进行 重用 。 每 个 模式 需要 描述 的 三 个 重 
要 方面 (Buschmann et al. 1996) 是 上 下 文 、 问 题 和 解决 方案 。 上 下 文 是 指 产生 问题 的 环境 ， 
问题 是 指 在 上 下 文中 会 重复 出 现 的 问题 ， 而 解决 方案 则 是 指 一 种 对 于 问题 的 可 行 性 方案 。 描 
述 模式 的 模板 通常 还 需要 描述 模式 的 优 缺 点 以 及 一 些 相 关 的 模式 。 一 个 标准 的 模式 描述 模板 
大 约 是 这 样 的 : 

e 模式 名 。 

• 别名 。 该 模式 已 知 的 其 他 名 称 。 

e 上 下 文 。 产 生 该 问题 的 环境 。 

• 问题 。 问 题 的 简要 描述 。 

e 解决 方案 的 总 结 。 解 决 方案 的 简要 描述 。 

e 解决 方案 的 优点 。 

e 解决 方案 的 缺点 。 
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e 适用 性 。 何 时 可 以 使 用 该 模式 。 

• 相关 的 模式 。 

© 参考 文献 。 可 以 找到 更 多 关于 该 模式 的 信息 的 地 方 。 

下 面 给 出 了 一 个 关于 分 层 模 式 描述 的 例子 。 本 书 中 所 介绍 的 所 有 模式 的 基于 该 标准 模板 
的 完整 描述 可 以 在 附录 А 中 找到 。 


模式 名 

别名 

上 下 文 

问题 

解决 方案 的 总 结 


抽象 分 层 

层次 化 分 层 、 抽 象 层 次 

软件 体系 结构 设计 

需要 设计 一 个 易于 扩展 和 收缩 的 软件 体系 结构 

较 低 层次 的 构件 向 较 高 层次 的 构件 提供 服务 。 每 一 层 的 构件 只 能 
使 用 较 低 层次 上 的 构件 所 提供 的 服务 


解决 方案 的 优点 
解决 方案 的 缺点 
适用 性 
相关 的 模式 


提高 了 软件 设计 的 可 扩展 性 和 可 收缩 性 
当 要 跨越 很 多 层 的 时 候 可 能 导致 效率 低下 
操作 系统 、 通 信 协 议 、 软 件 产 品 线 
内 核 可 以 是 抽象 分 层 体 系 结构 中 的 最 底层 
该 模式 的 变 体 包括 灵活 的 抽象 分 层 


参考 文献 第 12 章 12.3.1 47; Hoffman and Weiss 2001; Parnas 1979 





12.5 ”接口 设计 


面向 对 象 的 设计 和 基于 构件 的 软件 体系 结构 都 有 一 个 重要 的 目标 ， 就 是 将 接口 从 实现 中 
分 离 出 来 。 一 个 接口 明确 了 一 个 类 、 服 务 或 构件 的 外 部 可 见 操作 ， 而 不 需要 提供 其 内 部 关于 
该 操作 的 结构 〈 实 现 )。 接 口 可 以 认为 是 类 的 外 部 视图 的 设计 者 和 类 的 内 部 实现 的 实现 者 之 间 
的 一 种 约定 ， 同 时 也 是 需要 (使 用 ) 该 接口 的 类 ( 如 调用 该 接口 所 提供 的 操作 ) 和 提供 该 接 


ЗЕЕ РЕ, 
根据 信息 隐藏 的 思想 ( 见 4.2 节 )， 类 的 属性 是 私有 的 ， 而 





类 所 提供 的 公共 操作 构成 了 接口 。 在 使 用 类 图 表示 法 的 静态 模型 
中 ,接口 (类 操作 ) 在 表示 类 的 方 框 的 第 三 个 部 分 中 描述 。 在 
图 12-12 所 展示 的 例子 中 ， 在 表示 类 的 方 框 的 第 二 个 部 分 描述 了 
“账户 ”( Account ) 类 的 两 个 私有 属性 (“ 减 号 ”在 UML 图 中 表 
ЖАН )， 在 表示 类 的 方 框 的 第 三 个 部 分 描述 了 一 个 包含 五 个 公 
共 操 作 的 接口 (“加 号 ”在 UML 图 中 表示 公有 )。 


- accountNumber : Integer 
- balance : Real 


+ readBalance () : Real 
+ credit (amount : Real) 
+ debit (amount : Real) 
+ open (accountNumber : Integer) 
+ close () 






图 12-12 


带 有 公共 接口 和 私 
有 属性 的 类 示例 


由 于 同一 个 接口 可 以 以 不 同 的 方式 实现 ， 因 此 将 接口 设计 独立 于 实现 接口 的 构件 进行 描 
述 是 很 有 用 的 。 此 外 ， 接 口 可 以 在 除 类 之 外 的 其 他 上 下 文中 被 实现 。 因 此 ， 子 系统 、 分 布 式 


构件 以 及 被 动 类 中 的 接口 都 可 以 使 用 相同 的 接口 符号 来 描述 。 


接口 的 名 字 可 以 和 实现 它 的 类 或 构件 的 名 字 不 同 。 一 般 情况 下 ， 接 口 的 名 字 以 字母 “T" 


开头 。 在 UML 中 ， 一 个 接口 可 以 独立 于 实现 它 的 构件 进行 建 模 。 接 口 可 以 用 两 种 方式 来 进 
行 描 述 : 简单 描述 和 扩展 描述 。 在 简单 描述 中 ， 接 口 被 表示 成 一 个 小 圆圈 ， 在 圆圈 的 边 上 标 
注 接口 的 名 字 。 那 些 提 供 该 接口 的 类 或 构件 被 连接 到 这 个 小 圆圈 上 ， 如 图 12-13a 所 示 。 在 扩 
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展 描述 中 ， 接 口 被 表示 成 一 个 带 有 静态 建 模 符号 的 矩形 ， 如 图 12-136 Sta, ЭН — М 
分 中 标注 构造 型 « 接口 («interface») 和 接口 的 名 字 。 接 口 的 操作 在 矩形 的 第 三 个 部 分 中 进 
行 描述 。 和 矩形 的 第 二 个 部 分 是 空白 的 (注意 在 其 他 教材 中 ， 接 口 有 时 候 被 表示 成 两 个 部 分 ， 


中 间 的 空白 部 分 被 忽略 掉 )。 
d) 带 有 请 求 接口 的 构件 e) 请 求 构件 使 用 供给 构件 
| 所 提供 的 接口 


Operatorinteraction : | 
© IBasicAlarmService 


lIBasicAlarmService 


lIBasicAlarmService (С) 
BasicAlam 
Service 


a) 带 有 供给 接口 的 构件 














IBasicAlarmService 


BasicAlarm 
Service 








«interface» 
lIBasicAlarmService 


ee ш 
post(in alarm) 
ZS 
| 
| 
BasicAlarm 
Service 


с) 实现 接口 的 构件 








图 12-13 ”接口 和 实现 接口 的 类 示例 


一 个 接口 的 例子 是 IBasicAlarmService。 该 接口 提供 了 两 个 操作 ， 其 一 是 读 取 警 报 数据 ， 
其 二 是 发 布 新 的 警报 ， 如 下 所 示 : 

接口 : IBasicAlarmService 

所 提供 的 操作 : 

e alarmRequest (in request, out alarmData ) 

• post (in alarm ) 

实现 该 接口 的 构件 叫做 BasicAlarmService， 它 提供 了 对 于 该 接口 的 实现 。 在 
UML 中 ， 实 现 关 系 如 图 12-13c 那 样 表示 ( 带 有 一 个 三 角形 箭头 的 虚线 )， 这 表示 构件 
BasicAlarmService 实现 了 接口 IBasicAlarmService。 一 个 请 求 接口 会 被 表示 成 一 个 带 有 接口 名 
字 的 小 的 半圆 形 的 符号 ， 而 请 求 该 接口 的 类 或 者 构件 会 被 连接 到 这 个 半圆 上 ， 如 图 12-13d 所 
示 。 为 了 表示 一 个 带 有 请 求 接口 的 构件 使 用 了 一 个 带 有 供给 接口 的 构件 ， 那 个 带 有 请 求 接口 
的 半圆 (有 时 候 也 称 为 插 槽 ) 要 画 在 带 有 供给 接口 的 那个 圈 (有 时 候 也 称 为 球 ) 的 周围 ， 如 
图 12-13e 所 示 。 


12.6 ”设计 软件 体系 结构 


在 软件 设计 建 模 过 程 中 ,设计 决策 的 确定 与 软件 体系 结构 的 特性 密切 相关 。 接 下 来 的 章 

节 将 介绍 针对 不 同类 型 的 软件 体系 结构 的 设计 : 
ө 面向 对 象 的 软件 体系 结构 : 第 14 章 介绍 了 面向 对 象 的 设计 ， 其 中 使 用 了 信息 隐藏 、 类 
和 接口 的 概念 。 这 种 设计 方法 产生 的 是 顺序 性 的 面向 对 象 的 软件 体系 结构 设计 ， 这 种 
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软件 可 以 被 实现 为 只 有 一 个 控制 线程 的 顺序 性 程序 。 这 一 章 介绍 了 面向 对 象 的 软件 体 
系 结构 设计 ， 并 在 考虑 其 他 一 些 重要 的 软件 体系 结构 设计 思想 之 前 ， 清 楚 地 说 明了 面 
向 对 象 的 概念 是 如 何 被 应 用 于 其 中 的 。 
客户 端 /服务 器 软件 体系 结构 : 第 15 章 介 绍 了 客户 端 / 服 务 器 软件 体系 结构 的 设计 ， 
这 类 设计 通常 包含 一 个 服务 器 和 多 个 客户 端 。 对 这 种 设计 所 做 出 的 决策 需要 同时 考 
虑 服务 器 和 客户 端 : 它们 应 该 被 设计 成 顺序 的 还 是 并 发 的 子 系统 ， 应 该 使 用 什么 样 
的 模式 来 设计 各 个 子 系统 。 客 户 端 / 服 务 器 软件 体系 结构 和 体系 结构 模式 在 软件 系统 
中 是 十 分 普遍 的 ， 因 此 花 些 时 间 来 理解 这 些 系统 设计 过 程 中 的 根本 思想 和 相关 问题 是 
值得 的 。 
面向 服务 的 体系 结构 : 第 16 章 介绍 了 面向 服务 的 体系 结构 设计 ， 该 类 设计 通常 包含 多 
个 分 布 式 的 自治 服务 ， 而 这 些 服务 可 以 组 合成 分 布 式 的 软件 应 用 。 这 一 章节 介绍 了 如 
何 设计 面向 服务 的 体系 结构 ， 包 括 如 何 设计 服务 、 如 何 对 不 同 的 服务 进行 协调 以 及 如 
何 复 用 服务 。 面 向 服务 的 体系 结构 正在 被 越 来 越 多 地 使 用 ， 它 包含 了 客户 端 /服务 器 
系统 和 基于 构件 的 分 布 式 系统 的 概念 。 关 于 人 处理 面向 服务 的 体系 结构 的 一 些 体系 结构 
方面 的 问题 会 在 这 一 章 进行 阐述 。 
基于 构件 的 分 布 式 软件 体系 结构 : 第 17 章 介绍 了 基于 构件 的 软件 体系 结构 设计 。 这 一 
章 介 绍 了 一 些 用 于 构件 设计 的 构件 组 织 准 则 ， 这 样 的 构件 可 以 部 署 到 分 布 式 平台 上 执 
行 。 构 件 接口 的 设计 将 与 具有 服务 和 请 求 接口 的 端口 以 及 将 相 匹配 的 服务 和 请 求 端口 
连接 在 一 起 的 连接 器 一 起 介绍 。 基 于 构件 的 软件 体系 结构 使 用 UML 2 复合 结构 图 表示 
法 来 描述 。 分 布 式 应 用 经 常 是 基于 构件 的 ， 在 这 些 应 用 中 系统 的 确切 形态 依赖 于 所 使 
用 的 构件 技术 。 然 而 ， 这 类 系统 的 开发 中 仍然 存在 一 些 重要 的 体系 结构 思想 ， 这 些 将 
在 这 一 章 中 介绍 。 
并 发 及 实时 的 软件 体系 结构 : 第 18 章 介 绍 了 实时 软件 体系 结构 的 设计 ， 这 些 体 系 结 
构 是 并 发 的 ， 通 常 需要 处 理 多 个 输入 事件 流 。 这 类 系统 通常 是 状态 相关 的 ， 使 用 集中 
式 控制 或 者 分 散 式 控制 。 对 于 这 种 系统 ， 需 要 开发 一 个 并 发 的 软件 体系 结构 ， 其 中 系 
统 被 组 织 为 并 发 的 任务 ， 并 发 任务 之 间 的 接口 和 互联 关系 也 需要 定义 。 谍 人 式 的 实时 
软件 系统 在 软件 应 用 中 是 一 个 相当 重要 的 领域 。 许 多 用 来 描述 其 他 软件 体系 结构 的 思 
想 ( 如 信息 隐藏 和 并 发 ) 也 可 以 被 应 用 在 实时 设计 中 。 这 一 章 还 介绍 了 实时 软件 体系 
结构 设计 中 的 其 他 一 些 重要 问题 。 
软件 产品 线 体系 结构 : 第 19 章 介绍 了 软件 产品 线 体 系 结构 的 设计 ， 这 些 体系 结构 是 用 
于 构建 软件 产品 族 的 ， 需 要 同时 捕捉 产品 族 中 的 共性 和 可 变性 。 在 开发 软件 产品 线 体 
系 结构 时 ， 由 于 可 变性 管理 所 导致 的 复杂 性 的 增加 ， 开 发 单个 软件 体系 结构 的 问题 变 
得 更 加 突出 。 软 件 产品 线 的 概念 可 以 应 用 于 所 有 之 前 描述 的 体系 结构 中 ， 因 为 其 阐述 
了 在 软件 家 族 中 的 共性 和 可 变性 的 观点 。 软 件 产 品 线 体系 结构 也 是 对 演化 系统 进行 显 
式 建 模 的 一 种 自然 的 选择 ， 因 为 演化 中 的 每 一 个 版 本 都 可 以 认为 是 软件 家 族 中 的 一 个 
成 员 。 

第 20 章 介绍 了 软件 体系 结构 的 质量 属性 ， 这 些 质 量 属性 阐述 了 软件 的 非 功能 性 需求 ， 并 
且 对 于 软件 产品 的 质量 有 着 深远 的 影响 。 很 多 质量 属性 都 可 以 在 软件 体系 结构 开发 时 进行 考 
虑 和 评估 。 软 件 质量 属 性 包括 可 维护 性 、 可 修改 性 、 可 测试 性 、 可 追踪 性 、 可 伸缩 性 、 可 复 
用 性 、 性 能 、 可 用 性 及 安全 性 。 
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本 章 对 软件 体系 结构 进行 了 概览 ， 介 绍 了 软件 体系 结构 的 多 视图 ， 特 别 是 静态 、 动 态 和 
部 署 视图 。 本 章 的 介绍 有 助 于 在 设计 总 体 的 软件 体系 结构 时 考虑 应 用 软件 体系 结构 模式 ， 包 
括 体 系 结构 的 结构 模式 和 体系 结构 的 通信 模式 。 体 系 结构 的 结构 模式 用 于 设计 软件 体系 结构 
的 总 体 结构 ， 它 阐述 了 系统 是 如 何 由 子 系统 构成 的 。 例 如 抽象 分 层 模 式 就 是 一 种 体系 结构 的 
结构 模式 ， 这 在 此 前 的 章节 中 进行 了 较为 详细 的 描述 。 软 件 体系 结构 的 通信 模式 考虑 子 系统 
之 间 相 互通 信 的 方式 。 此 前 的 章节 中 对 于 三 种 体系 结构 的 通信 模式 ， 即 调用 /返回 模式 、 异 
步 消 息 通 信 模 式 以 及 带 同步 消息 通信 模式 进行 了 较为 详细 的 介绍 。 每 一 个 子 系统 的 设计 都 通 
过 某 种 方式 使 得 它 所 提供 的 操作 以 及 所 使 用 的 操作 可 以 由 接口 明确 定义 。 分 布 式 子 系统 之 间 
的 通信 可 以 是 同步 的 也 可 以 是 异步 的 。 

在 软件 设计 建 模 的 过 程 中 ,设计 决策 的 确定 与 软件 体系 结构 的 特性 密切 相关 。 第 13 章 
介绍 了 从 分 析 到 设计 的 转换 以 及 如 何 将 系统 组 织 为 一 系列 子 系统 。 第 14 章 介 绍 了 使 用 信息 隐 
藏 、 类 以 及 接口 概念 的 面向 对 象 的 设计 。 第 15 章 介绍 了 客户 端 /服务 器 体系 结构 的 设计 ， 这 
类 体系 结构 通常 包含 一 个 服务 器 和 多 个 客户 端 。 第 16 章 介 绍 了 面向 服务 的 体系 结构 设计 ， 这 
类 体系 结构 通常 包含 多 个 分 布 式 的 自治 服务 ， 这 些 服务 可 以 组 合成 分 布 式 的 软件 应 用 。 第 17 
章 介绍 了 基于 构件 的 软件 体系 结构 设计 ， 包 括 构件 接口 的 设计 以 及 包含 服务 和 请 求 接口 的 构 
件 端口 、 将 相互 匹配 的 端口 连接 在 一 起 的 连接 器 的 设计 。 第 18 章 介绍 了 实时 软件 体系 结构 的 
设计 ， 这 类 体系 结构 是 并 发 的 体系 结构 ， 通 常 需要 处 理 多 个 输入 事件 流 。 第 19 章 介绍 了 软件 
产品 线 体系 结构 的 设计 ， 这 是 一 种 面向 软件 产品 族 的 软件 体系 结构 ， 需 要 同时 捕 提 产品 族 中 
的 共性 和 可 变性 。 

第 20 章 介绍 了 软件 体系 结构 的 软件 质量 属性 以 及 它们 是 如 何 被 用 来 评估 软件 体系 结构 的 
质量 的 。 第 21 至 24 章 提供 了 一 系列 关于 如 何 应 用 COMET/UML 来 建 模 和 设计 不 同 软件 体系 
结构 的 案例 研究 。 


练习 
选择 题 ( 每 道 题 选择 一 个 答案 ) 


1. 软件 体系 结构 描述 了 什么 ? 

(а) 在 一 幢 建 筑 中 的 软件 (b) 客户 端 /服务 器 系统 的 结构 
(с) 软件 系统 的 总 体 结构 (4) 软件 类 以 及 它们 之 间 的 关系 
2. 关于 构件 下 面 哪 一 句 话 是 错误 的 ? 

(а) 一 个 由 其 他 对 象 组 成 的 复合 对 象 (b) 一 个 操作 

(с) 一 个 简单 对 象 (d) 提供 一 个 接口 

3. 软件 体系 结构 的 结构 视图 是 什么 ? 

(а) 体现 为 模块 层次 的 视图 (b ) 体现 为 构件 和 连接 器 的 视图 


(с) 体现 为 结 点 和 互联 关系 的 物理 配置 视图 (а) 体现 为 对 象 和 消息 的 视图 
4. 软件 体系 结构 的 动态 视图 是 什么 ? 

(a) 体现 为 模块 层次 的 视图 (b ) 体现 为 构件 和 连接 器 的 视图 
(с) 体现 为 结 点 和 互联 关系 的 物理 配置 视图 (а) 体现 为 对 象 和 消息 的 视图 
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5. 软件 体系 结构 的 部 署 视图 是 什么 ? 

(a) 体现 为 模块 层次 的 视图 (b) 体现 为 构件 和 连接 器 的 视图 

(с) 体现 为 结 点 和 互联 关系 的 物理 配置 视图 (а) 体现 为 对 象 和 消息 的 视图 
6. 什么 是 软件 体系 结构 模式 ? 

(а) 一 个 系统 中 主要 子 系统 的 结构 (b) 软件 体系 结构 中 的 构件 和 连接 器 
(с) 一 组 互相 协作 的 对 象 (d) 在 不 同系 统 中 重复 出 现 的 体系 结构 
7. 在 抽象 分 层 模式 中 会 发 生 什 么 ? 

(a) 每 一 层 都 只 能 使 用 相 邻 的 下 一 层 的 服务 

(b) 每 一 层 都 只 能 使 用 相 邻 的 上 一 层 的 服务 

(с) 每 一 层 都 只 能 使 用 相 邻 的 上 一 层 和 下 一 层 的 服务 

(4) 每 一 层 相 对 于 其 他 层 而 言 都 是 独立 的 
8. 在 调用 /返回 模式 中 会 发 生 什么 ? 

(а) 调用 对 象 中 的 一 个 调用 操作 向 被 调用 对 象 中 的 一 个 操作 ( 又 称 方法 ) 发 送 了 一 条 消息 
(b ) 调用 对 象 中 的 一 个 调用 操作 调用 了 一 个 被 调用 对 象 中 的 操作 ( 又 称 为 方法 ) 

(с) 调用 对 象 等 待 被 调用 对 象 的 应 答 

( 4) 调用 对 象 不 等 待 被 调用 对 象 的 应 答 
9. 一 个 生产 者 向 一 个 消费 者 发 送 了 一 条 消息 。 下 面 所 列 的 哪 种 情况 是 异步 消息 通信 ? 
(а) 生产 者 等 待 消费 者 的 应 答 (b) 生产 者 不 等 待 消费 者 的 应 答 

(с) 生产 者 进入 休眠 (4) 生产 者 等 待 超时 
10. 一 个 生产 者 向 一 个 消费 者 发 送 了 一 条 消息 。 下 面 所 列 的 哪 种 情况 是 带 回复 的 同步 信息 

通信 ? 

(а) 生产 者 等 待 消费 者 的 应 答 (b ) 生产 者 不 等 待 消费 者 的 应 答 

(с) ТА ЖЕ (а) 生产 者 等 待 超时 
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在 分 析 建 模 时 ， 问 题 是 通过 分 解 以 及 逐个 考虑 各 个 用 例 的 方式 来 分 析 的 。 在 设计 建 模 时 ， 
解决 方案 是 通过 设计 一 个 定义 了 软件 系统 的 结构 和 行为 属性 的 软件 体系 结构 来 构造 的 。 为 了 
成 功 地 管理 大 型 软件 系统 开发 所 固有 的 复杂 性 ， 我 们 需要 一 种 能 够 将 系统 分 解 为 子 系统 以 及 
开发 系统 的 总 体 软 件 体系 结构 的 方法 。 完 成 分 解 后 ， 每 个 子 系统 都 可 以 按照 后 续 章 节 中 所 介 
绍 的 方式 独立 进行 各 自 的 设计 。 
13.1 节 介 绍 了 软件 体系 结构 设计 中 的 问题 。 设 计 软 件 体系 结构 需要 从 分 析 模 型 开始 。 此 
外 ， 在 设计 软件 体系 结构 时 ， 还 需要 做 出 一 些 决策 : 
ө 如 何 将 基于 用 例 的 交互 模型 整合 到 一 个 初始 的 软件 体系 结构 中 ， 这 将 在 13.2 节 中 介 
绍 。 

• 如 何 使 用 关注 点 分 离 和 子 系统 组 织 标准 来 确定 系统 所 包含 的 子 系统 ， 这 将 在 13.3 节 和 
13.4 节 中 分 别 介绍 。 

e 如 何 确定 子 系统 间 消 息 通信 的 确切 类 型 ， 这 将 在 13.5 节 中 介绍 。 


13.1 软件 体系 结构 设计 中 的 问题 


进行 问题 域 分 析 以 及 将 系统 划分 为 子 系统 的 过 程 中 ， 重 点 都 在 于 如 何 通 过 功能 分 解 使 得 
每 个 子 系统 都 明确 地 负责 处 理 系统 的 一 个 部 分 〈 详 见 13.3 节 )。 设计 目标 是 让 每 个 子 系统 都 
能 负责 执行 一 个 与 其 他 子 系统 功能 相对 独立 的 主要 功能 。 一 个 子 系统 还 可 以 被 进一步 分 解 成 
更 小 的 子 系统 ， 其 中 每 个 子 系统 完成 一 部 分 功能 子 集 。 这 样 ， 当 定义 好 子 系统 之 间 的 接口 之 
后 ， 就 可 以 独立 进行 各 个 子 系统 的 设计 了 。 

一 些 子 系统 由 于 地 理 位 置 上 的 分 布 以 及 服务 器 职责 的 区 分 可 以 相对 容易 地 确定 下 来 。 地 
理 分 布 最 常见 的 一 种 形式 是 客户 端 和 服务 ， 一 般 会 被 分 配 到 不 同 的 子 系统 中 : 一 个 客户 端 
子 系统 和 一 个 服务 子 系统 。 因 此 ， 图 13-1 中 “银行 系统 ”的 软件 体系 结构 由 一 个 位 于 每 台 
АТМ 机 上 的 “ATM 客户 端 ” 子 系统 和 一 个 “银行 服务 ” 子 系统 组 成 。 这 是 一 个 地 理 位 置 分 
布 的 子 系统 组 织 的 例子 ， 其 中 系统 的 地 理 位 置 分 布 是 在 问题 描述 中 给 出 的 。 在 这 种 情况 下 ， 
子 系统 的 组 织 可 以 在 设计 过 程 的 早期 完成 。 


sendATMTransaction 
(in transaction, out response) 
一 一 下 

















«client» 
«subsystem» 
: ATMClient 


«service» 
«subsystem» 
: BankingService 








图 13-1 高 层 软件 体系 结构 : 银行 系统 


在 其 他 一 些 应 用 中 ， 如 何 将 系统 分 解 为 子 系统 就 没 那么 显而易见 了 。 子 系统 分 解 的 目标 
之 一 是 让 功能 相关 、 高 度 耦 合 的 对 象 处 于 同一 子 系统 中 ， 因 此 用 例 是 一 个 好 的 起 点 。 参 与 同 
一 个 用 例 的 对 象 可 以 看 作 归 属 同一 子 系统 的 候选 者 。 因 此 ， 子 系统 分 解 一 般 是 在 通过 动态 建 


160 着 三 部 分 RRA 


Ж Сло) 确定 每 个 用 例 的 组 成 对 象 之 间 的 交互 之 后 进行 的 。 需 要 注意 的 是 ， 正 如 本 章 
所 描述 的 那样 ， 子 系统 分 解 可 以 在 设计 阶段 的 早期 进行 。 

子 系统 提供 了 一 个 比 对 象 粒 度 更 大 的 信息 隐藏 解决 方案 。 子 系统 分 解 可 以 从 系统 的 用 例 
开始 。 实 现 同一 个 用 例 的 对 象 需要 相互 通信 (如 基于 用 例 的 交互 图 所 描述 的 )， 因 此 具有 更 高 
的 耦合 度 ， 而 且 与 其 他 用 例 中 对 象 的 耦合 度 较 低 (或 者 无 耦合 )。 然 而 ， 一 个 对 象 可 能 会 参与 
多 个 用 例 之 中 ,但 只 能 属于 一 个 子 系统 。 因 此 ， 一 个 参与 多 个 用 例 的 对 象 需要 考虑 如 何 分 配 到 
一 个 子 系统 中 ， 通 常 这 个 子 系统 与 该 对 象 的 耦合 度 最 高 。 在 某 些 情况 下 ， 一 个 子 系统 可 能 会 同 
时 包含 来 自 多 个 用 例 的 对 象 ， 这 种 情况 最 有 可 能 发 生 在 多 个 功能 上 相关 的 用 例 共享 一 些 共同 对 
象 的 时 候 。 然 而 ， 有 些 时 候 也 存在 参与 同一 个 用 例 的 多 个 对 象 需要 被 分 配 到 不 同 子 系统 之 中 的 
情况 (例如 由 于 它们 位 于 不 同 的 地 理 位 置 上 )。 这 些 问题 将 在 13.3 节 中 作 进 一 步 讨 论 。 


13.2 ”集成 通信 图 


为 了 实现 从 分 析 到 设计 的 过 渡 并 确定 子 系统 ， 有 必要 在 已 经 进行 的 分 析 基 础 上 合成 一 个 
初始 的 软件 设计 。 这 可 以 通过 集成 作为 动态 模型 一 部 分 的 基于 用 例 的 交互 图 来 进行 。 虽 然 对 
象 间 的 动态 交互 也 可 以 通过 顺序 图 或 通信 图 来 描述 ， 但 这 里 的 集成 使 用 了 通信 图 ， 因 为 通信 
图 能 够 形象 地 描述 对 象 之 间 的 相互 连接 以 及 所 传递 的 消息 。 

在 分 析 模 型 中 ， 应 当 至 少 为 每 个 用 例 开发 一 个 通信 图 。 集 成 通信 图 是 所 有 开发 用 来 支持 
用 例 的 通信 图 的 合成 ， 它 实际 上 是 对 相关 通信 图 的 合并 。 接 下 来 将 介绍 集成 通信 图 是 如 何 开 
发 的 。 

不 同 用 例 之 间 通 常 存 在 执行 的 优先 顺序 。 通 信和 图 合成 的 顺序 应 该 与 用 例 执行 的 顺序 一 致 。 
从 可 视 化 的 角度 看 ， 集 成 是 以 下 面 的 方式 完成 的 。 从 第 一 个 用 例 的 通信 图 开始 ， 将 第 二 个 用 
例 的 通信 图 秋 加 到 第 一 个 上 面 形成 一 个 集成 的 图 。 接 着 ,将 第 三 个 图 倒 加 到 集成 的 前 两 个 的 
图 上 ， 以 此 类 推 。 每 次 攻 加 时 ， 从 每 个 后 面 的 图 中 向 集成 的 图 中 添加 新 的 对 象 和 消息 交互 。 
随 着 大 加 的 对 象 和 消息 交互 越 来 越 多 ， 图 也 变 得 越 来 越 大 。 那 些 出 现在 多 个 通信 图 中 的 对 象 
和 消息 交互 只 会 显示 一 次 。 

需要 注意 的 是 ， 集 成 通信 图 必须 显示 由 单个 基于 用 例 的 通信 图 中 派生 得 到 的 所 有 消息 通 
信 。 通 信 图 通常 通过 一 个 用 例 显 示 主 要 的 交互 序列 ， 但 并 不 显示 所 有 可 能 的 序列 。 在 集成 通 
信 图 中 ， 有 必要 显示 各 个 用 例 中 执行 主 序列 之 外 的 其 他 备 选 序列 所 产生 的 消息 通信 。 第 11 章 
中 给 出 了 一 个 在 “银行 系统 ”中 支持 “验证 PIN 码 ” 用 例 中 的 主 序 列 和 几 个 备 选 序列 的 交互 
图 的 例子 。 所 有 这 些 附加 的 消息 都 应 当 出 现在 集成 通信 图 上 ， 从 而 使 集成 通信 图 成 为 对 象 间 
所 有 消息 通信 的 一 个 完整 的 描述 。 

集成 通信 图 是 所 有 相关 的 基于 用 例 的 通信 图 的 合成 ， 显 示 了 所 有 对 象 以 及 它们 之 间 的 交 
互 。 集 成 通信 图 用 泛 化 的 UML 通信 图 ( 见 12.2.2 节 ) 表示 ， 这 意味 着 它 描 述 了 对 象 间 所 有 
可 能 的 交互 。 在 集成 通信 图 中 ， 对 象 和 消息 会 被 显示 ， 而 消息 序列 编号 则 没 必要 显示 ， 因 为 
这 样 做 只 会 增加 混乱 。 如 13.5 节 所 述 ， 与 基于 用 例 的 通信 图 一 样 ， 在 决定 消息 通信 的 类 型 
( 同步 或 异步 ) 之 前 ， 集 成 通信 图 上 的 消息 会 被 描述 成 简单 消息 。 

图 13-2 给 出 了 一 个 “银行 系统 ”的 “ATM 客户 端 ” 子 系统 的 集成 通信 图 的 例子 。 这 个 
例子 由 实现 了 “银行 系统 ”7 个 用 例 的 通信 图 集成 得 到 ， 包 括 每 个 用 例 的 主 序列 和 其 他 备 选 
序列 。 集 成 通信 图 是 一 个 泛 化 图 ， 因 此 对 象 的 名 字 没 有 加 下 划 线 。 
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由 于 集成 通信 图 在 大 型 系统 中 将 会 变 得 非常 复杂 ， 因 此 有 必要 减少 图 中 的 信息 量 。 一 
个 减少 图 中 信息 量 的 方法 是 对 消息 进行 聚合 ， 即 如 果 一 个 对 象 向 另 一 个 对 象 发 送 了 多 条 消 
息 ， 那 么 使 用 一 个 聚合 消息 而 不 是 在 图 上 显示 所 有 这 些 消 息 。 聚 合 消息 是 一 种 能 够 有 效 减 少 
集成 通信 图 中 的 混乱 的 方法 。 聚 合 消息 并 不 表示 从 一 个 对 象 发 送 到 另 一 个 对 象 的 实际 消息 ， 
而 是 一 对 相同 的 对 象 之 间 在 不 同时 刻 发 送 的 消息 。 例 如 ， 图 13-2 中 从 “ATM 控制 ”( ATM 
Control ) 对 象 发 送 到 “客户 交互 ”( Customer Interaction) 对 象 的 消息 可 以 被 聚合 为 一 个 称 为 
“显示 提示 ”( Display Prompts) 的 聚合 消息 ， 如 表 13-1 所 示 。 图 13-2 中 其 他 聚合 消息 的 例 
子 还 包括 “ATM 交易 ”( АТМ Transactions )、“ 银 行 应 答 ”( Bank Responses ) 和 “客户 事件 ” 
(Customer Events )。 这 个 集成 通信 图 的 例子 将 会 在 第 21 章 的 “银行 系统 ”案例 分 析 中 详细 
描述 。 
表 13-1 由 简单 消息 组 成 的 聚合 消息 
聚合 消息 由 简单 消息 组 成 


Get PIN, Invalid PIN Prompt, Display Menu, Display Cancel, Display Menu, Display 


Display P t 
ыы Confiscate, Display Eject 


此 外 ， 将 所 有 对 象 都 显示 在 一 个 图 上 可 能 是 不 现实 的 。 这 个 问题 的 一 个 解决 方案 是 为 每 
个 子 系统 开发 集成 通信 图 ， 并 且 开 发 一 个 高 层 的 子 系统 通信 图 来 显示 子 系统 间 的 交互 ， 正 如 
接 下 来 所 描述 的 那样 。 

子 系统 间 的 动态 交互 可 以 在 一 个 子 系统 通信 图 上 描述 ， 这 个 图 是 一 个 高 层 的 集成 通信 图 ， 
如 图 13-1 中 的 “银行 系统 ”的 例子 所 示 。 每 一 个 子 系统 的 结构 可 以 在 一 个 集成 通信 图 上 描 
述 ， 该 图 显示 了 子 系统 中 所 有 的 对 象 以 及 其 相互 连接 关系 ， 如 图 13-2 所 示 。 





13.3” 子 系 统 设计 中 的 关注 点 分 离 


在 设计 子 系统 时 需要 做 出 一 些 重要 的 组 织 决策 。 下 列 这 些 解 决 关 注 点 分 离 问题 的 设计 考 
虑 应 当 包 含 在 系统 的 子 系统 分 解 设计 过 程 中 ， 其 目的 是 使 得 子 系统 的 独立 性 更 好 从 而 可 以 让 
不 同 的 子 系统 关注 不 同 的 关注 点 。 


13.3.1 复合 对 象 


属于 同一 个 复合 对 象 一 部 分 的 对 象 应 该 在 同一 个 子 系统 中 ， 并 且 应 该 与 那些 不 属于 该 复 
合 对 象 的 对 象 相 分 离 。 如 第 7 章 所 述 ， 聚 合 与 组 合 都 是 整体 /部 分 关系 ， 而 组 合 是 一 种 更 强 
的 聚合 形式 。 在 组 合 关系 中 ， 复 合 对 象 (整体 ) 和 它 的 组 成 对 象 ( 部 分 ) 一 起 被 创建 、 一 起 
生存 然后 又 一 起 消亡 。 因 此 ， 一 个 由 复合 对 象 和 其 组 成 对 象 构 成 的 子 系统 比 一 个 由 聚合 对 象 
和 其 组 成 对 象 构成 的 子 系统 的 耦合 度 更 高 。 

与 单个 对 象 相 比 ， 子 系统 在 更 高 的 抽象 层次 上 支持 信息 隐藏 。 软 件 对 象 可 以 被 用 来 建 模 
问题 域 中 的 现实 世界 对 象 ， 而 复合 对 象 建 模 问 题 域 中 复合 的 现实 世界 对 象 。 一 个 复合 对 象 通常 
由 多 个 经 协调 共同 工作 的 相关 对 象 组 成 ， 这 种 安排 类 似 于 制造 业 的 装配 结构 。 一 个 应 用 经 常 需 
要 一 个 复合 对 象 的 多 个 实例 (因此 也 包含 其 每 个 组 成 对 象 的 多 个 实例 )。 一 个 复合 类 和 其 组 成 
类 之 间 的 关系 最 适合 在 静态 模型 中 描述 ， 因 为 类 图 可 以 描述 每 个 组 成 类 和 复合 类 之 间 关 联 关系 
的 重 数 。 

一 个 复合 类 的 例子 是 “自动 取款 机 ”( ATM ) 类 (И 13-3). АТМ 是 一 个 由 ATM 读 卡 器 、 
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吐 钞 器 、 赁 条 打印 机 和 АТМ 客户 键盘 / 显示 器 组 成 的 复合 类 。 在 银行 系统 中 有 多 个 АТМ Я 
合 类 的 实例 ， 其 中 每 一 个 都 代表 一 台 自动 取款 机 。 






ATMCustomer 
KeypadDisplay 





1 


可 以 将 聚合 子 系统 作为 一 种 包含 复合 子 系统 (构件 ) 的 高 层 子 系统 。 一 个 聚合 子 系统 包 
括 一 组 根据 功能 相似 性 聚集 在 一 起 的 对 象 ， 这 些 对 象 可 以 跨越 地 理 位 置 的 边界 。 这 些 聚 合 对 
象 被 聚集 在 一 起 是 因为 它们 在 功能 上 的 相似 性 或 者 在 同一 个 用 例 中 存在 交互 关系 。 与 复合 子 
系统 相 比 ， 聚 合子 系统 可 以 被 方便 地 作为 更 高 层次 上 的 抽象 ， 尤 其 是 在 一 个 包含 很 多 构件 的 
高 度 分 布 式 的 应 用 中 。 在 一 个 跨越 多 个 组 织 的 软件 体系 结构 中 ， 将 每 个 组 织 描述 为 一 个 聚合 
子 系统 是 很 有 用 的 。 分 层 体 系 结构 也 可 以 按照 将 每 层 设 计 为 一 个 聚合 子 系统 的 方式 来 组 织 。 
每 一 层 自身 也 可 以 包括 多 个 地 理 上 分 布 的 复合 子 系统 (被 设计 为 构件 或 服务 o “应 急 监控 系 
统 ” 案 例 研究 是 一 个 将 每 一 层 (用 户 、 监 控 、 服 务 ) 设计 成 一 个 聚合 子 系统 的 软件 体系 结构 
的 例子 ， 如 图 13-4 所 示 以 及 如 第 23 章 所 述 。 每 一 层 包 括 一 个 或 更 多 的 复合 子 系统 ( 构件 或 
服务 )。 因 此 ， 监 控 层 有 两 个 构件 :“ 监 控 传 感 器 构件 ”( MonitoringSensor Component ) 和 “ 远 
程 系统 代理 ”( RemoteSystem Proxy); 服务 层 有 两 个 服务 :“ 和 警报 服务 ”( Alarm Service) 和 
“监控 数据 服务 ”( Monitoring Data Service )。 
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Я 13-3 复合 类 示例 : ATM 
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13.3.2 地理 位 置 


如 果 两 个 对 象 有 可 能 会 分 布 在 不 同 的 地 理 位 置 上 ,那么 它们 应 该 位 于 不 同 的 子 
系统 中 。 在 一 个 分 布 式 环 境 中 ， 基 于 构件 的 子 系统 之 间 只 能 通过 彼此 间 发 送 消息 的 方 
式 进 行 通信 。 在 图 13-5 所 描述 的 “应 急 监 控 系 统 ” 的 部 署 图 中 ,“ 监 控 传 感 器 构件 ” 
(MonitoringSensor Component ) “远程 系统 代理 ”( RemoteSystem Proxy ) 和 “操作 员 展 
现 ”( Operator Presentation ) 构件 都 拥有 多 个 实例 。 此 外 ， 还 有 两 个 服务 构件 ， 即 “警报 
服务 ”( Alarm Service ) 和 “监控 数据 服务 ”( Monitoring Data Service )。 这 些 构件 的 每 个 
实例 都 有 可 能 在 物理 上 位 于 一 个 不 同 的 微型 计算 机 结 点 上 ， 这 些 结 点 位 于 不 同 的 地 理 位 置 
并 通过 广域网 连接 。 
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图 13-5 地 理 分 布 示例 : 应 急 监 控 系 统 


13.3.3 ”客户 端 和 服务 


客户 端 和 服务 应 该 在 不 同 的 子 系统 中 。 这 条 准则 可 以 被 看 作 地 理 位 置 规则 的 一 个 特例 ， 
因为 客户 端 和 服务 通常 位 于 不 同 的 位 置 。 例 如 ,图 13-1 中 的 “银行 系统 ”拥有 很 多 相同 类 型 
В) “АТМ 客户 端 ” 子 系统 ， 这 些 子 系统 位 于 分 布 在 全 国 各 地 的 物理 ATM Я Е. “银行 服务 ” 
位 于 一 个 集中 的 位 置 ， 例 如 在 纽约 市 。 图 13-4 所 示 的 “应 急 监 控 系 统 ” 中 有 两 个 服务 ， 即 
“警报 服务 ”( Alarm Service ) 和 “监控 数据 服务 ”( Monitoring Data Service )， 分 别 位 于 与 它 
们 的 客户 端 不 同 的 子 系统 中 。 


13.3.4 用户 交互 


作为 一 个 更 大 的 分 布 式 配置 一 部 分 ， 用 户 经 常 使 用 他 们 自己 的 个 人 电脑 ， 因 此 最 灵活 
的 选择 是 让 用 户 交 互 对 象 位 于 独立 的 子 系统 中 。 因 为 用 户 交互 对 象 通常 是 客户 端 ， 这 条 准则 
可 以 被 看 作 是 客户 端 /服务 准则 的 一 个 特殊 情况 。 此 外 ， 一 个 用 户 交互 对 象 可 能 是 一 个 由 几 
个 简单 用 户 交 互 对 象 组 成 的 复合 图 形 用 户 交 互 对 象 。 图 13-6 中 的 “操作 员 展 现 ”( Operator 
Presentation ) 构件 是 一 个 复合 图 形 用 户 交 互 对 象 的 例子 ， 其 中 包括 三 个 简单 的 图 形 交 互 对 
象 ， 即 一 个 “操作 员 交 互 ”( Operator Interaction) 对 象 、 一 个 “警报 窗口 ”( Alarm Window ) 
和 一 个 “事件 监控 窗口 ”( Event Monitoring Window )。 第 17 章 对 此 有 更 详细 的 介绍 。 


13.3.5 ”外 部 对 象 的 接口 
一 个 子 系统 处 理 用 例 模 型 中 的 一 部 分 参与 者 以 及 上 下 文 图 中 的 一 部 分 外 部 现实 世界 对 
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象 。 一 个 外 部 现实 世界 对 象 应 该 只 与 一 个 子 系统 之 间 存 在 接口 。 图 13-7 描述 了 “ATM 客户 
端 ” 子 系统 的 一 个 例子 ， 其 中 , “АТМ 客户 端 ”与 多 个 外 部 现实 世界 类 之 间 存 在 接口 ， 包 括 
“ 读 卡 器 ““ 吐 钞 器 ”和 “和 赁 条 打印 机 "， 而 这 些 外 部 对 象 只 与 系统 中 的 АТМ 客户 端子 系统 
之 间 有 接口 。 


«user interaction» 
«component» 
OperatorPresentation 





«user interaction» «user interaction» “er interaction» 
AlarmWindow ratorInt: ti EventMonitoring 
OperatorInteraction Window 
图 13-6 用 户 交互 子 系统 示例 
«external output device» 
ReceiptPrinter 
«software system» 
BankingSystem 


1 1 
«external input/output N «client» 


device» «subsystem» 
CardReader у ATMClient 





«external output device» 
CashDispenser 
«extemal user» 
ATMCustomer 


Я 13-7 “与 外 部 类 之 间接 口 示例 


13.3.6 ”控制 范围 


一 个 控制 对 象 及 其 所 直接 控制 的 所 有 实体 和 输入 /输出 〈IO ) 对 象 都 应 该 位 于 同一 个 子 
系统 之 中 ， 而 不 是 分 散在 多 个 子 系统 之 中 。 一 个 例子 就 是 图 13-2 中 “ATM 客户 端 ” 子 系统 
中 的 “ATM 控制 ”( ATM Control) 对 象 ， 该 对 象 提 供 了 ATM 客户 端子 系统 中 所 有 对 象 的 总 
体 控制 ， 包 括 几 个 内 部 输入 /输出 对 象 ( 例如 “ 读 卡 器 接口 ”和 “ 吐 钞 器 接口 ”" )、 用 户 交互 
对 象 (例如 “客户 交互 ”对 象 ) 和 实体 对 象 (例如 “ATM 交易 ”对 象 )。 
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13.4 子 系统 组 织 准则 


上 述 各 节 描 述 的 设计 考虑 可 以 被 规范 定义 为 子 系统 组 织 准 则 ， 其 目的 是 确保 子 系统 设计 
的 有 效 性 。 本 节 中 子 系统 组 织 准 则 将 通过 示例 来 进行 描述 。 一 个 子 系 统 可 以 满足 不 止 一 个 的 
组 织 准则 。 子 系统 通常 使 用 构造 型 ( stereotype ) «subsystem» 来 描述 。 构 造型 «component» 用 
于 描述 某 些 由 分 布 式 基 于 构件 的 子 系统 组 成 的 软件 体系 结构 中 的 子 系统 ， 而 构造 型 «service» 
则 用 于 描述 在 由 服务 子 系统 组 成 的 面向 服务 的 体系 结构 中 的 服务 子 系统 。 


1341 客户 端子 系统 


一 个 客户 端子 系统 是 一 个 或 多 个 服务 的 请 求 者 。 客 户 端 存在 多 种 不 同 的 类 型 ， 有 些 可 
能 全 部 依赖 于 某 个 服务 ， 而 另外 一 些 可 能 只 是 部 分 依赖 于 某 个 服务 。 前 者 仅仅 与 一 个 服务 通 
信 ， 而 后 者 可 能 与 多 个 服务 进行 通信 。 客 户 端子 系统 包括 用 户 交 互 子 系统 、 控 制 子 系统 和 输 
入 /输出 子 系统 ， 这 些 将 分 别 在 13.4.2 节 ‚13.4.4 WA 13.4.6 节 进 行 详细 介绍 。 在 一 些 应 用 中 ， 
一 个 客户 端子 系统 将 多 种 角色 组 合 在 一 起 。 例 如 ， 图 13-1 中 “银行 服务 ”的 一 个 客户 端子 系 
统 “ATM 客户 端 ” 同 时 具有 用 户 交 互 和 控制 特性 。 

图 13-4 中 所 描述 的 “应 急 监 控 系 统 ” 有 两 个 服务 子 系统 ， 即 “警报 服务 ”和 “监控 数据 
服务 ”"。“ 监 控 传感器 构件 ”"、“ 远 程 系 统 代 理 ” 和 “操作 员 展 现 ” 构 件 是 “警报 服务 ”和 “ 监 
控 数 据 服务 ”的 客户 端 。 


13.4.2 用户 交互 子 系统 


用 户 交 互 子 系统 提供 用 户 接口 ， 并 且 充 当 一 个 客户 端 / 服 务 系统 中 的 客户 端 角色 ， 提 供 
用 户 访问 服务 。 同 一 个 系统 中 的 用 户 交互 子 系统 可 能 有 多 个 ， 每 种 类 型 的 用 户 一 个 。 一 个 用 
户 交互 子 系统 通常 是 一 个 由 几 个 简单 用 户 交 互 对 象 组 成 的 复合 对 象 ， 其 中 可 能 包括 一 个 或 多 
个 本 地 存储 和 /或 缓存 的 实体 对 象 以 及 总 体 用 户 输入 和 输出 序列 的 控制 对 象 。 

随 着 图 形 工作 站 和 个 人 电脑 的 增长 ， 提 供用 户 交 互 角色 的 子 系统 可 以 在 一 个 单独 的 结 点 
上 运行 ， 并且 与 其 他 结 点 上 的 子 系统 交互 。 用 户 交 互 子 系统 可 以 对 完全 由 结 点 支持 的 简单 请 
求 提供 快速 响应 ， 而 对 需要 与 其 他 结 点 协作 处 理 的 请 求 的 响应 则 相对 较 慢 。 这 类 子 系统 通常 
需要 与 特定 的 用 户 输入 /输出 设备 建立 接口 ， 例 如 图 形 显示 和 键盘 。 图 13-1 中 的 “ATM 客户 
端 ” 子 系统 满足 这 一 准则 。 

一 个 用 户 交 互 客户 端子 系统 可 以 支持 包括 命令 行 界面 或 者 包含 多 个 对 象 的 图 形 用 户 界 面 
的 简单 用 户 接 口 。 一 个 简单 的 用 户 交互 客户 端子 系统 可 以 只 有 一 个 控制 线程 。 

一 个 更 复杂 的 用 户 交 互 子 系统 通常 包括 多 个 窗口 和 多 个 控制 线程 。 例 如 ， 一 个 Windows 
客户 端 由 多 个 独立 运行 的 窗口 组 成 ， 每 个 窗口 都 有 一 个 拥有 自己 独立 的 控制 线程 的 并 发 对 象 
来 提供 支持 。 这 些 并 发 对 象 可 能 会 访问 一 些 共享 数据 。 

13-8 展示 了 一 个 基本 “应 急 监控 系统 ”中 的 用 户 交 互 子 系统 的 例子 。“ 基 本 操作 员 展 
现 ”( Basic Operator Presentation ) 是 一 个 拥有 多 个 实例 的 用 户 交互 子 系统 。 每 个 实例 都 会 向 
“警报 服务 ”和 “监控 数据 服务 ” 子 系统 发 送 请 求 。“ 基 本 操作 员 展 现 ” 子 系统 拥有 一 个 内 部 
用 户 交互 对 象 来 显示 “警报 窗口 ”中 的 告警 ， 而 另 一 个 内 部 用 户 交 互 对 象 来 显示 “事件 监控 
窗口 ”中 的 监控 状态 。 
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13.4.3 ”服务 子 系统 


服务 子 系统 为 客户 端子 系统 提供 服务 。 服 务 子 系统 并 不 会 发 起 任何 请 求 ， 但 是 会 对 来 自 
客户 端子 系统 的 请 求 进行 响应 。 服 务 子 系统 是 任何 一 个 提供 服务 的 子 系统 ， 服 务 于 客户 端 请 
求 。 服 务 子 系统 通常 是 由 两 个 或 更 多 对 象 组 成 的 复合 对 象 。 这 些 对 象 包括 实体 对 象 、 服 务 客 
户 端 请 求 并 决定 应 该 将 请 求 分 配给 哪些 对 象 处 理 的 协调 者 对 象 、 封 装 应 用 逻辑 的 业务 逻辑 对 
象 。 一 个 服务 经 常 与 一 个 或 多 个 数据 存储 相关 联 ， 或 者 提供 数据 库 访 问 。 另 一 种 情形 是 ， 服 
务 可 能 与 一 个 或 多 个 输入 /输出 设备 相关 联 ， 例 如 一 个 文件 服务 或 行 式 打印 机 服务 。 

一 个 服务 子 系统 通常 会 被 分 配 一 个 属于 自己 的 结 点 。 一 个 数据 服务 支持 对 一 个 集中 式 数 
据 库 或 文件 存储 的 远程 访问 。 一 个 输入 /输出 服务 负责 处 理 针对 驻 留 在 同一 结 点 上 的 物理 资 
源 的 请 求 。 图 13-8 和 图 13-9 中 的 “警报 服务 ”和 “监控 数据 服务 ” 子 系统 是 数据 服务 子 系统 


的 例子 ， 其 中 分 别 存储 了 当前 和 历史 告警 以 及 传感器 数据 。 
: Operator 
Presentation 
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(in request, out alarmData) 
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«service» 
: AlarmService 


Р 13-9 ”服务 子 系统 示例 











«service» 
: Monitoring 
DataService 


{Layer 1} 


13.4.4 HIF RSE 


一 个 控制 子 系统 控制 系统 中 的 一 个 给 定 部 分 。 控 制 子 系统 接收 来 自 外 部 环境 的 输入 ， 产 
生 面 向 外 部 环境 的 输出 ， 其 中 通常 没有 任何 人 工 干 预 。 一 个 控制 子 系统 通常 是 状态 相关 的 ， 
在 这 种 情况 下 该 子 系统 包含 至 少 一 个 状态 相关 的 控制 对 象 。 在 有 些 情况 下 ， 一 些 输 入 数据 可 
能 要 通过 其 他 子 系统 收集 然后 被 该 子 系统 使 用 。 另 一 种 情况 是 ， 该 子 系统 可 能 会 提供 数据 给 
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其 他 子 系统 使 用 。 

一 个 控制 子 系统 可 以 从 另 一 个 给 予 其 总 体 方 向 的 子 系统 那里 接收 一 些 高 层 命 令 ， 然 后 持 
续 地 或 者 以 按 需 的 方式 向 其 他 结 点 提供 低层 控制 或 发 送 状态 信息 。 

图 13-1 PAY “АТМ 客户 端 ” 子 系统 是 一 个 控制 子 系统 的 例子 ， 该 子 系统 将 控制 和 用 户 
交互 两 种 角色 结合 起 来 。“ATM 客户 端 ” 有 多 个 实例 ， 每 个 АТМ 机 一 个 ， 其 中 每 个 实例 都 
独立 于 其 他 实例 ， 并 且 只 和 “银行 服务 ” 子 系统 进行 通信 。 “АТМ 客户 端 ” 的 控制 角色 是 
对 一 系列 相关 的 交互 进行 顺序 控制 ， 包 括 与 АТМ 客户 的 交互 、 与 “银行 服务 ” 子 系统 的 通 
信 ， 以 及 对 提取 现金 、 打 印 赁 条 和 读 取 与 弹出 (或 没收 АТМ 卡 的 输入 /输出 设备 的 控制 。 
这 一 控制 角色 在 ATM 机 的 状态 图 中 进行 了 明确 的 描述 ， 其 中 状态 图 的 动作 触发 了 控制 对 象 
的 动作 。 

另 一 个 例子 是 图 13-10 中 “自动 引导 车 辆 系统 ”( Automated Guided Vehicle ) 的 一 个 控制 
子 系 统 。 在 该 子 系统 中 ， 控 制 是 由 一 个 状态 相关 的 内 部 控制 对 象 “车辆 控制 ”提供 的 ( 图 中 
未 显示 )， 此 对 象 从 “监管 系统 ”接收 行驶 命令 ， 控 制 发 动机 构件 (用 来 启动 和 停止 沿 轨道 的 
行驶 ) 和 操作 臂 构件 (用 来 装载 和 钊 载 部 件 )， 这 些 会 在 第 24 章 进行 详细 描述 。“ 自动 引导 车 
辆 系统 ”向 “监管 系统 ”发 送 车 辆 确认 ， 向 “显示 系统 ”发 送 车 辆 状态 。 


«coordinator» 
«subsystem» .| 
: SupervisorySystem 








Move Command $ | Vehicle Ack 


П 
«control» 
«subsystem» 
: AutomatedGuidedVehicle 
System 


图 13-10 工厂 自动 化 系统 中 的 控制 和 协调 者 子 系统 示例 
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: DisplaySystem 














13.4.5 协调 者 子 系统 


协调 者 子 系统 协调 其 他 子 系统 的 执行 ， 例 如 控制 子 系统 或 服务 子 系统 。 接 下 来 会 介绍 这 
两 类 协调 者 子 系统 。 

在 拥有 多 个 控制 子 系统 的 软件 体系 结构 中 ， 有 时 通过 一 个 协调 者 子 系统 对 这 些 控制 子 系 
统 进 行 协调 是 必要 的 。 如 果 多 个 控制 子 系统 是 完全 相互 独立 的 ， 如 图 13-1 中 的 АТМ 客户 端 ， 
那么 协调 是 不 需要 的 。 在 其 他 情况 下 ， 控 制 子 系统 可 以 协调 多 个 控制 子 系统 之 间 的 活动 。 如 果 
协调 相对 简单 ， 那 么 这 种 分 布 式 协调 通常 是 可 能 的 。 如 果 协 调 活动 相对 复杂 ， 那 么 使 用 层次 化 
的 控制 系统 以 及 一 个 监管 这 些 控制 子 系统 的 独立 的 协调 者 子 系统 是 比较 好 的 选择 。 例 如 ， 协 调 
者 子 系统 可 以 决定 一 个 控制 子 系统 接 下 来 应 该 完成 哪 一 个 项 工作 。“ 工 厂 自动 化 系统 ”中 包含 
一 个 协调 者 子 系统 向 控制 子 系统 分 配 工作 项 的 例子 。 在 这 个 系统 中 ,“ 监 管 系统 ”( 图 13-10) 
是 一 个 向 各 个 “自动 引导 车 辆 系统 ”分 配 工作 的 协调 器 ， 这 些 工作 包括 移动 到 一 个 工作 站 、 装 
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载 一 个 部 件 并 将 其 运送 到 另 一 个 工作 站 。 

另 一 种 协调 者 子 系统 决定 多 个 服务 子 系统 的 执行 序列 〈 也 称 作 工 作 流 )， 这 些 会 在 第 16 
章 进行 详细 介绍 。 在 线 购 物 系 统 中 的 “客户 协调 者 ”是 一 个 面向 服务 体系 结构 中 的 协调 者 的 
例子 。“ 客 户 协调 者 ”从 “客户 交互 ”构件 那里 接收 购物 请 求 ， 然 后 与 “目录 服务 "、“ 客 户 账 
户 服务 ”" “信用 卡 服 务 ” 和 “电子 邮件 服务 ”等 服务 子 系统 交互 ， 如 图 13-11 所 示 。 
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图 13-11 面向 服务 体系 结构 中 协调 者 子 系统 示例 


1346 输入 /输出 子 系统 


一 个 输入 、 输 出 或 输入 /输出 子 系统 是 一 个 代表 其 他 子 系统 执行 输入 和 /或 输出 操作 的 子 
系统 ， 这 种 子 系统 可 以 设计 为 相对 比较 自治 的 子 系统 。 例 如 ,“ 智 能 ”设备 可 以 具有 更 强 的 本 
地 自治 能 力 ， 可 以 由 硬件 以 及 作为 设备 接口 并 负责 设备 控制 的 软件 组 成 。 一 个 输入 /输出 子 
系统 通常 由 一 个 或 更 多 的 设备 接口 对 象 组 成 并且 还 可 能 包括 提供 本 地 化 控制 的 控制 对 象 和 
存储 本 地 数据 的 实体 对 象 。 

输入 子 系统 的 一 个 例子 是 图 13-9 所 描述 的 应 急 监 控 系 统 中 的 “监控 传感器 构件 ”， 该 构 
件 从 外 部 传感器 那里 接收 输入 ， 它 是 两 个 服务 的 客户 端 : 向 “警报 服务 ”发 布 警报 、 向 “ 监 
控 数 据 服务 ”发 布 事件 。 


13.5 子 系统 间 消 息 通 信和 的 决策 


在 从 分 析 模 型 到 设计 模型 的 过 渡 中 ， 最 重要 的 决策 之 一 就 是 与 子 系统 之 间 需 要 哪 种 类 
型 的 消息 通信 相关 。 男 一 个 相关 的 决策 是 更 精确 地 确定 每 条 消息 的 名 称 和 参数 ( 即 接口 规 
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约 )。 分 析 模 型 中 没有 确定 消息 通信 的 类 型 。 此 外 ， 分 析 模 型 强调 的 是 在 对 象 间 传 递 的 消 
息 ， 而 不 是 精确 的 消息 名 称 和 参数 。 在 设计 建 模 过 程 ， 当 子 系统 结构 被 确定 后 (如 13.4 节 
所 示 )， 需 要 确定 消息 通信 的 准确 语义 ， 例 如 消息 通信 是 同步 还 是 异步 的 ( 见 第 4 章 和 第 
12%), 

两 个 子 系统 间 的 消息 通信 可 以 是 单 向 或 是 双向 的 。 图 13-12а 描述 了 一 个 生产 者 和 消费 者 
间 单 向 消息 通信 的 分 析 模 型 的 例子 以 及 一 个 客户 端 和 服务 间 双 向 消息 通信 的 例子 。 分 析 模 型 
中 所 有 的 消息 使 用 的 都 是 同一 种 表示 法 ( 棍 状 箭头 )， 因 为 此 时 消息 通信 的 具体 类 型 还 未 确 
定 。 这 一 问题 将 在 设计 时 确定 ， 因 此 设计 者 现在 需要 确定 这 些 例子 中 需要 哪 种 类 型 的 消息 通 
fa (消息 通信 的 UML 表示 法 概述 见 2.8 节 )。 

图 13-12b 展示 了 两 个 设计 决策 的 结果 。 首 先 ， 图 13-12a 中 的 四 个 分 析 模型 对 象 在 图 13-12b 
中 被 设计 成 并 发 子 系统 。 其 次 ， 关 于 子 系统 间 消 息 通 信 的 类 型 被 确定 。 图 13-12b 描述 了 在 生产 
者 和 消费 者 之 间 使 用 异步 消息 通信 的 决策 以 及 在 客户 端 和 服务 之 间 使 用 同步 消息 通信 的 决策 。 
此 外 ， 每 条 消息 确切 的 名 称 和 参数 也 被 确定 下 来 。 该 异步 消息 (在 UML 2 P, RARR 
步 消 息 ) 的 名 称 是 “send Asynchronous Message” 并 具有 名 为 “message” 的 消息 内 容 。 同 步 消 息 
(在 UML 2 中 ,黑色 箭头 表示 同步 消息 ) 的 名 称 是 “send Synchronous Message With Reply”, В. 
有 名 为 “message” 的 输入 内 容 和 名 为 “response” 的 服务 响应 。 


Message 
aProducer aConsumer 


(1) 生产 者 和 消费 者 之 间 的 单 向 消息 通信 








| Transaction 
aClient aService 
<— 
Response 


(2) 客户 端 和 服务 之 间 的 双向 消息 通信 
а) 分 析 模型 一 一 关于 并 发 和 消息 通信 的 决策 做 出 之 前 


sendAsynchronousMessage (in 


message) 
一 一 > 











aProducer aConsumer 


(3) 并 发 的 生产 者 和 并 发 的 消费 者 之 间 的 异步 消息 通信 


=| 


(4) 并 发 的 客户 端 与 并 发 的 服务 之 间 的 同步 消息 通信 
b) 设计 模型 一 一 关于 并 发 和 消息 通信 的 决策 做 出 之 后 


图 13-12 ”从 分 析 向 设计 过 渡 : 关于 并 发 和 消息 通信 的 决策 
上 述 关 于 异步 和 同步 通信 的 决策 可 以 被 规范 化 描述 为 体系 结构 通信 模式 ( 如 第 12 章 所 
述 )。 因 此 ， 生 产 者 和 消费 者 间 的 单 向 消息 应 用 了 异步 消息 通信 模式 ， 而 客户 端 和 服务 间 的 消 








sendSynchronousMessagewithReply (in message, out 
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[227] 息 和 响应 应 用 了 带 回复 的 同步 消息 通信 模式 。 


13.6 BS 


本 章 介绍 了 软件 体系 结构 设计 。 其 中 介绍 了 软件 体系 结构 的 总 体 设 计 ， 包 括 从 分 析 建 模 
过 渡 到 设计 建 模 的 过 程 中 需要 做 出 的 决策 。 子 系统 依据 它们 在 软件 体系 结构 中 所 扮演 的 角色 
进行 了 分 类 。 这 种 体系 结构 的 一 些 例子 将 会 在 第 21 章 到 第 24 章 中 的 案例 研究 中 介绍 。 

在 设计 总 体 软 件 体系 结构 时 ， 应 用 软件 体系 结构 模式 是 很 有 帮助 的 ， 包 括 体 系 结构 结构 
模式 和 体系 结构 通信 模式 。 体 系 结构 的 结构 模式 应 用 于 软件 体系 结构 的 总 体 结 构 设计 ， 解 决 
了 如 何 将 系统 分 解 为 子 系统 的 问题 。 体 系 结构 的 通信 模式 针对 的 是 子 系统 之 间 相 互通 信 的 方 
式 。 在 此 过 程 中 ， 每 个 子 系统 的 接口 都 用 其 所 提供 和 使 用 的 操作 进行 了 明确 的 定义 。 分 布 式 
子 系统 间 的 通信 可 以 是 同步 或 是 异步 的 。 

在 软件 设计 建 模 过 程 中 ,设计 决策 的 做 出 与 软件 体系 结构 的 一 些 特性 相关 。 第 14 章 介 
绍 了 使 用 信息 隐藏 、 类 和 继承 这 些 思想 的 面向 对 象 设计 。 第 15 章 介 绍 了 客户 端 / 服 务 软件 
体系 结构 的 设计 ， 这 类 设计 的 典型 结构 包括 一 个 服务 和 多 个 客户 端 。 第 16 章 介绍 了 面向 服 
务 体系 结构 的 设计 ， 这 种 设计 通常 由 多 个 可 以 组 成 分 布 式 软件 应 用 的 分 布 式 自治 服务 组 成 。 
第 17 章 介绍 了 基于 构件 的 软件 体系 结构 ， 包 括 构件 接口 设计 、 带 有 供给 接口 和 请 求 接口 的 
构件 端口 的 设计 以 及 连接 相 匹配 端 口 的 连接 器 的 设计 。 第 18 章 介 绍 了 实时 软件 体系 结构 的 
设计 ， 这 是 一 种 通常 要 处 理 多 个 输入 事件 流 的 并 发 体系 结构 。 第 19 章 介绍 了 软件 产品 线 体 
系 结构 的 设计 ， 这 是 一 种 面向 软件 产品 组 的 体系 结构 ， 需 要 同时 捕捉 软件 族 中 的 共性 和 可 
变性 。 





练习 


选择 题 ( 每 道 题 选择 一 个 答案 ) 

1. 什么 是 集成 通信 图 ? 

(a) 通过 将 对 象 结合 在 一 起 形成 的 通信 图 

СБ) 所 有 支持 相关 用 例 的 通信 图 的 合成 

(с) 描述 了 实现 一 个 用 例 的 所 有 对 和 象 的 通信 图 

(а) 集成 了 来 自 静 态 模 型 中 的 对 象 的 通信 图 

2. 下 列 哪些 对 象 应 该 被 分 配 到 同一 个 子 系统 中 ? 

(а) 属于 同一 个 复合 对 象 一 部 分 的 对 象 Cb) 客户 端 和 服务 对 象 


(c) 用 户 接口 和 实体 对 象 (d) 彼此 相关 联 的 对 象 
З. 地 理 位 置 不 同 的 对 象 应 该 : 

(a) 在 同一 个 子 系统 中 (b) 在 不 同 的 子 系统 中 
(с) 在 一 个 复合 子 系统 中 (d) 在 分 层 子 系统 中 


4. 如 果 在 子 系统 组 织 中 使 用 了 控制 范围 ， 那 么 : 

Ca) 一 个 用 户 接口 对 象 与 所 更 新 的 实体 对 象 位 于 同一 个 子 系统 中 
(а) 一 个 状态 相关 的 控制 对 象 与 所 控制 的 对 象 位 于 同一 个 子 系统 中 
(с) 一 个 状态 相关 的 控制 对 象 与 所 控制 的 对 象 位 于 不 同 的 子 系统 中 
(4) 一 个 用 户 接口 对 象 与 所 更 新 的 实体 对 象 位 于 不 同 的 子 系统 中 
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5. 一 个 外 部 对 象 与 系统 的 接口 应 该 如 何 设 计 ? 


(a) 它 应 该 与 一 个 子 系统 建立 接口 (b) 它 应 该 与 多 个 子 系统 建立 接口 
(с) 它 应 该 与 每 个 子 系统 建立 接口 (4) 它 应 该 不 与 任何 子 系统 建立 接口 
6. 一 个 用 户 接口 子 系统 是 一 种 : 

(а) 控制 子 系统 (b) 服务 子 系统 

(c) 客户 端子 系统 (d) 输入 /输出 子 系统 

7. 下 列 哪些 对 象 不 太 可 能 位 于 同一 个 子 系统 中 ? 

(a) 用 户 接口 对 象 和 实体 对 象 (b) 状态 相关 的 控制 对 象 和 协调 者 对 象 
(с) 业务 逻辑 对 象 和 实体 对 象 (4) 输入 /输出 对 象 和 状态 相关 的 控制 对 象 
8. 下 列 哪个 子 系统 不 太 可 能 是 一 个 客户 端子 系统 ? 

(a) 控制 子 系统 (b) 用 户 交 互 子 系统 

(c) 服务 子 系统 (4) 输入 /输出 子 系统 


9. 什么 时 候 需要 一 个 协调 者 子 系统 ? 

(а) 当 子 系统 需要 协调 多 个 内 部 对 象 时 

(b) 当 子 系统 需要 协调 多 个 输入 /输出 设备 时 
(с) 当 子 系统 从 多 个 客户 端子 系统 接收 消息 时 
(4) 当 子 系统 需要 协调 其 他 子 系统 的 执行 时 
10. 什么 时 候 需要 一 个 控制 子 系统 ? 

(a) 当 子 系统 需要 控制 多 个 内 部 对 象 时 

(b) 当 子 系统 需要 控制 多 个 输入 /输出 设备 时 
(с) 当 子 系统 需要 控制 多 个 客户 端子 系统 时 
(а) 当 子 系统 需要 控制 其 他 子 系统 的 执行 时 


第 14 章 | 


Software Modeling & Design: UML, Use Cases, Patterns, & Software Architectures 


设计 面向 对 象 的 软件 体系 结构 





面向 对 象 的 思想 是 软件 设计 的 基础 。 面 向 对 象 设 计 是 指使 用 信息 隐藏 、 类 和 继承 的 思想 
设计 的 软件 系统 。 对 象 是 对 类 的 实例 化 并 通过 操作 〈 也 称 为 方法 ) 进行 访问 。 

类 使 用 信息 隐藏 的 思想 进行 设计 以 封装 不 同类 型 的 信息 ,例如 数据 结构 或 状态 机 的 实现 
细节 。 这 些 类 最 初 是 在 分 析 建 模 过 程 中 的 对 象 和 类 组 织 阶 段 中 确定 的 ， 如 第 8 章 所 述 。 本 章 
将 介绍 类 接口 和 每 个 类 提供 的 操作 的 设计 ， 还 将 介绍 软件 设计 中 继承 的 使 用 。 第 4 章 中 介绍 
了 信息 隐藏 、 类 和 继承 和 概念 。 正 如 第 4 章 所 述 ， 操 作 这 个 术语 的 含义 同时 包括 一 个 对 象 所 
执行 的 一 个 功能 的 规约 和 实现 。 

14.1 节 概 述 设计 顺序 性 面向 对 象 体系 结构 所 使 用 的 概念 、 体 系 结构 和 模式 。14.2 节 介绍 
在 设计 信息 隐藏 类 时 的 一 些 重要 问题 。14.3 节 介 绍 类 接口 和 操作 的 设计 ， 以 及 如 何在 动态 模 
型 基础 上 确定 接口 和 操作 。 接 下 来 的 各 节 介绍 了 不 同 种 类 的 信息 隐藏 类 的 设计 : 14.4 介绍 封 
装 数据 结构 的 数据 抽象 类 的 设计 ; 14.5 节 介绍 封装 有 限 状态 机 的 状态 机 类 的 设计 ; 14.6 节 介 
绍 隐藏 用 户 界面 细节 的 图 形 用 户 交 互 类 的 设计 ; 14.7 节 介 绍 封装 业务 规则 的 业务 逻辑 类 的 设 
计 。14.8 节 介 绍 面向 对 象 设计 中 的 继承 ,包括 类 继承 、 抽 象 类 和 子 类 的 设计 。14.9 节 描 述 类 
接口 规约 的 设计 ， 包 括 类 操作 的 规约 。14.10 节 介 绍 信息 隐藏 类 的 详细 设计 。14.11 节 介 绍 多 
态 和 动态 绑 定 。14.12 节 介 绍 用 Java 实现 的 类 的 例子 。 


14.1 面向 对 象 的 软件 体系 结构 的 概念 、 体 系 结构 和 模式 


信息 隐藏 是 一 个 基本 的 设计 思想 ， 实 现 信息 隐藏 的 类 封装 了 一 些 对 系统 其 他 部 分 隐藏 的 
信息 ， 例 如 数据 结构 。 类 的 设计 者 需要 确定 哪些 信息 应 该 隐藏 在 类 中 ， 哪 些 信 息 应 该 放 在 类 
的 接口 中 。 另 一 个 重要 的 思想 是 接口 与 实现 相 分 离 ， 这 样 接口 就 成 为 接口 的 提供 者 和 接口 的 
使 用 者 之 间 的 一 种 契约 。 更 多 关于 信息 隐藏 思想 的 细节 可 以 在 第 4 章 找 到 。 

本 章 介绍 顺序 性 面向 对 象 软件 体系 结构 的 设计 ， 这 种 设计 通常 被 实现 为 拥有 一 个 控制 线 
程 的 顺序 性 程序 。 面 向 对 象 的 思想 同样 也 在 分 布 式 和 基于 构件 的 软件 体系 结构 、 并 发 实时 软 
件 体系 结构 、 面 向 服务 的 体系 结构 和 软件 产品 线 体系 结构 中 得 到 了 应 用 和 扩展 ， 这 些 将 在 后 
面 的 章节 中 介绍 。 对 于 对 象 间 的 通信 ， 调 用 /返回 模式 是 顺序 性 体系 结构 中 唯一 的 通信 模式 ， 
如 第 12 章 所 述 。 | 


14.2 ”设计 信息 隐藏 类 


在 设计 建 模 阶 段 ， 信 息 隐 藏 类 可 以 使 用 构造 型 (stereotype ) 进行 分 类 。 根 据 分 析 模 型 
(第 8 章 ) 确定 的 类 ( 即 那些 来 自 于 问题 域 的 类 ) 被 分 为 实体 类 、 边 界 类 、 控 制 类 和 应 用 逻辑 
类 。 其 中 有 些 类 更 可 能 会 被 设计 为 主动 (并 发 ) 类 ,这 将 在 后 续 章 节 中 进行 介绍 ， 而 本 章 将 
主要 关注 那些 更 可 能 被 设计 成 被 动 类 的 类 。 

o 实体 类 。 在 分 析 模 型 中 确定 的 封装 数据 的 类 。 在 类 图 中 可 以 用 构造 型 5 实体 (entity ) 
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来 描述 实体 类 。 实 体 对 象 ( 即 实体 类 的 实例 ) 通常 是 用 来 存储 信息 的 持久 性 对 象 。 对 
于 基于 数据 库 的 应 用 程序 ， 所 封装 的 数据 很 有 可 能 需要 存储 在 数据 库 中 。 此 时 ， 实 体 
类 会 提供 一 个 数据 库 访问 接口 而 不 是 封装 数据 。 因 此 ， 在 类 设计 中 ， 实 体 类 被 进一步 
分 为 封装 数据 结构 的 数据 抽象 类 和 包装 器 类 。 包 装 器 类 隐藏 了 访问 现 有 系统 或 遗留 系 
统 的 接口 细节 ， 可 能 是 访问 存储 在 文件 管理 系统 或 数据 库 管理 系统 中 的 数据 。 数 据 库 
包装 器 类 隐藏 了 访问 存储 在 数据 库 ( 通常 是 关系 数据 库 ) 中 的 数据 的 方式 。 包 装 器 类 
也 可 以 隐藏 如 何 访问 遗留 系统 接口 的 细节 。 包 装 器 类 将 在 第 15 章 介绍 。 

边界 类 。 与 外 部 环境 通信 并 建立 接口 。 边 界 类 (例如 设备 的 输入 /输出 类 和 代理 类 ) 
经 常 是 主动 (并发) 类 ， 因 此 将 在 第 18 章 中 介绍 。 本 章 介 绍 的 一 个 被 动 的 边界 类 是 
图 形 用 户 交互 类 ,这 种 类 为 用 户 提供 访问 接口 并 为 他 们 呈现 信息 。 

ө 控制 类 。 为 一 组 对 象 提供 总 体 协调 。 控 制 类 经 常 是 主动 ( 并 发 ) 类， 因此 将 在 第 18 
章 中 介绍 。 本 章 介绍 的 一 种 被 动 控制 类 是 封装 了 有 限 状 态 机 的 状态 机 类 。 协 调 者 类 和 
计时 器 类 一 般 被 认为 是 主动 类 ( 任务 )， 因 此 并 不 在 本 章 介绍 。 

应 用 逻辑 类 。 封 装 特定 应 用 的 逻辑 和 算法 ， 可 以 分 为 业务 逻辑 类 、 服 务 类 和 算法 类 。 
业务 逻辑 类 在 本 章 中 介绍 。 服 务 类 在 第 16 章 面向 服务 的 体系 结构 中 介绍 。 算 法 类 经 
常 是 主动 的 ， 将 在 第 18 章 进 行 介绍 。 


14.3 ”设计 类 接口 和 操作 


如 第 13 章 所 述 ， 类 接口 由 每 个 类 提供 的 操作 组 成 。 每 个 操作 有 输入 参数 、 输 出 参数 和 
《如果 是 一 个 函数 的 话 ) 一 个 返回 值 。 类 的 操作 可 以 根据 静态 模型 或 动态 模型 确定 。 虽 然 静态 
模型 可 以 用 于 显示 每 个 类 的 操作 ， 但 是 基于 动态 模型 确定 类 的 操作 通常 会 更 容易 ， 尤 其 是 通 
信和 图 或 顺序 图 。 这 是 因为 动态 模型 能 够 显示 对 象 间 的 消息 交互 ， 因 此 能 够 反映 消息 的 对 象 中 
被 调用 的 操作 。 被 动 对 象 间 传递 的 消息 由 一 个 对 象 中 调用 另 一 个 对 象 提 供 的 操作 的 操作 组 成 。 
一 些 类 设计 的 例子 将 会 在 本 章 中 给 出 。 


14.3.1 基于 交互 模型 设计 类 操作 


本 节 介 绍 了 如 何 使 用 对 象 交 互 模型 来 帮助 确定 每 个 类 的 操作 。 顺 序 图 或 通信 图 都 可 以 用 
于 此 目的 。 因 此 ， 一 个 类 的 操作 可 以 通过 考虑 一 个 从 类 的 实例 化 对 象 如 何 与 其 他 对 象 交互 来 
确定 。 特 别 地 ， 当 两 个 对 象 交 互 时 ， 一 个 对 象 为 另 一 个 对 象 提供 一 个 操作 。 本 节 介 绍 了 类 操 
作 的 设计 ， 从 交互 图 开始 ， 然 后 在 类 图 上 展示 操作 设计 。 

如 果 两 个 对 象 交 互 ， 那 么 需要 知道 是 其 中 哪 一 个 对 象 调 用 了 另 一 个 对 象 的 操作 。 这 种 信 
息 通常 无 法 根据 一 个 静态 模型 中 的 类 图 来 确定 ， 因 为 静态 模型 只 显示 了 类 间 的 静态 关系 。 另 
一 方面 ， 动 态 交 互 模型 描述 了 一 个 对 象 向 另 一 个 对 象 发 送 消息 的 方向 。 如 果 将 对 象 映射 到 一 
个 顺序 程序 中 ， 发 送 消息 的 对 象 调用 接收 消息 的 对 象 的 操作 。 此 时 ， 消 息 被 映射 为 一 个 操作 
调用 。 消 息 的 名 字 映 射 为 操作 的 名 称 ， 消 息 的 参数 映射 为 操作 的 参数 。 

对 象 的 操作 可 以 直接 根据 其 所 在 的 交互 图 来 确定 。 分 析 模 型 中 所 强调 的 是 捕捉 对 象 间 传 
递 的 信息 ， 而 不 是 操作 的 准确 语法 。 因 此 ， 通 信和 图 上 的 消息 可 能 是 个 名 词 ( 反映 所 传递 的 数 
据 )， 也 可 能 是 个 动词 (反映 所 要 执行 的 操作 )。 

在 设计 模型 中 ， 需 要 定义 类 的 操作 。 如 果 消 息 显示 为 一 个 名 词 ， 那 么 此 时 需要 定义 接收 
信息 的 对 象 的 操作 。 如 果 消 息 显示 为 一 个 动词 ,那么 该 动词 表示 操作 的 名 称 。 在 设计 模型 中 ， 
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操作 的 名 称 反 映 类 提供 的 服务 这 一 点 是 十 分 重要 的 。 

此 外 还 需要 考虑 操作 是 否 包含 输 入 和 /或 输出 参数 。 在 分 析 模 型 中 ， 通 信 图 中 的 消息 通 
常 被 描述 为 从 发 送 对 象 向 接收 对 象 发 送 的 简单 消息 。 在 某 些 情况 下 ， 一 个 简单 消息 表示 对 前 
一 个 消息 的 应 答 。 所 有 调用 操作 的 消息 在 设计 模型 通信 图 中 都 被 描述 为 同步 消息 。 分 析 模 型 
中 所 描述 的 实际 表示 应 答 的 简单 消息 ( 即 操作 所 返回 的 数据 ) 被 映射 为 操作 的 返回 参数 。 

除了 将 变量 作为 操作 的 参数 进行 传递 外 ， 也 可 以 将 对 象 作为 参数 传递 。 对 象 一 旦 被 创建 
后 ， 就 可 以 作为 调用 其 他 对 象 的 操作 的 参数 。 一 个 例子 是 “银行 系统 ”中 的 “ATM 交易 ” 实 
体 类 。 一 旦 一 个 交易 ( 例如 “PIN 码 验证 交易 ”) 被 创建 后 ， 该 对 象 便 可 以 作为 “ATM 交易 ” 
的 参数 从 “ATM 客户 端 ” 传 递 到 “银行 服务 ”。 


14.3.2 ”基于 交互 模型 设计 类 操作 示例 


作为 一 个 基于 对 象 交互 模型 设计 类 操作 的 例子 ， 考 虑 “ATM Е” (АТМ Сага) 类 (如 
14.4 节 所 述 的 数据 抽象 类 )， 其 中 封装 了 从 АТМ 卡 中 读 取 的 信息 。 通 过 检查 图 14-1a 中 的 分 
析 模 型 通信 图 可 以 发 现 “ 读 卡 器 接口 ”( Сага Reader Interface ) 对 象 发 送 了 三 个 数据 项 : 将 存 
WETE “ATM 卡 ” 实 体 对 象 中 的 “ 卡 ID”(Card Id), “Eih HH” (Start Date) 和 “失效 日 期 ” 
( Expiration Date ) ( 此 前 从 АТМ 卡 中 读 取 出 来 的 )。 此 后 ,“ 客 户 交 互 ”( Customer Interaction ) 
对 象 向 “ATM 卡 ” 发 送 了 一 个 “ 卡 请 求 ”( Сага Request ) 消息 ， 返 回 相 同 的 三 个 数据 项 。 在 设 
计 过 程 中 需要 确定 精确 的 类 接口 设计 。 因 为 这 三 个 数据 项 被 写 人 АТМ 卡 ， 所 以 设计 模型 ( 见 
图 1415) 中 设计 了 一 个 名 为 write “ATM 卡 ” 数 据 抽象 对 象 的 操作 ， 该 操作 拥有 三 个 输入 
参数 (“ 卡 ID”“ 开 始 日 期 “失效 日 期 ”") “客户 交互 ”对 象 发 送 的 “ 卡 请 求 ” 消 息 被 设计 成 
一 个 “ATM 卡 ” 对 象 提 供 的 read 操作 。ATM 卡 返回 的 三 个 数据 项 被 设计 为 read 操作 返回 的 输 
出 参数 (“ 卡 ID”、“ 开 始 日 期 “失效 日 期 " )。 操 作 调用 使 用 UML 同步 消息 表示 法 来 描述 。 























«ИО» 
: CardReader 
Interface 


«МО» 
: CardReader 
Interface 





W1: Card Id, Start Date, aN 


Expiration Date 
«entity» 
: ATMCard 


R1.1: Card Id, Start Date, R1: read(out cardld, out startDate, 
К1: Card Request Expiration Date out expirationDate) 


W1: write(cardid, тете 
expirationDate) 





«data 
abstraction» 
: ATMCard 





«user interaction» 
: Customer 
Interaction 


«user interaction» 
: Customer 
Interaction 


a) 分 析 模 型 : 通信 图 b) 设计 模型 : 通信 图 


«data abstraction» 
ATMCard 











- аітСага!а: String 
- atmStartDate: Date 
- atmExpirationDate: Date 








+ write (in cardld, in startDate, in expirationDate) 
+ read (out cardid, out startDate, out expirationDate) 


с) 设计 模型 : 类 图 
图 14-1 数据 抽象 类 示例 
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根据 通信 图 确定 对 象 的 操作 后 ， 操 作 将 与 提供 操作 的 类 一 起 在 静态 模型 中 进行 描述 。 因 
此 ， 将 基于 通信 图 确定 类 操作 以 及 在 类 图 上 进行 描述 这 二 者 相 结合 进 行 处 理 是 有 帮助 的 。 这 
个 方法 的 使 用 贯穿 本 章 。 

因此 ， 图 14-1c 描述 了 “ATM 卡 ” 数 据 抽象 类 。 在 “ATM 卡 ” 类 中 封装 了 相关 属性 。 这 
些 属性 被 描述 为 私有 属性 ， 因 此 对 外 部 其 他 类 是 不 可 见 的 。 这 些 属性 通过 write 操作 存储 ， 通 
过 read 操作 访问 。 类 接口 通过 公共 的 read 和 write 操作 以 及 每 个 操作 的 参数 来 定义 。 


14.3.3 ”基于 静态 模型 设计 类 操作 


通过 静态 模型 中 的 类 图 确定 类 操作 是 可 能 的 ， 尤 其 是 对 实体 类 。 标 准 的 操作 包括 create 
(创建 )、read (ВЕНА), update ( 更新) FI delete (WER )。 然 而 ,通常 可 以 通过 定义 类 所 提供 
的 服务 来 按照 特定 的 数据 抽象 类 的 特定 需要 对 操作 进行 裁剪 。 这 将 在 后 面 几 节 中 通过 一 些 类 
操作 设计 的 例子 进行 解释 。 


14.4 ”数据 抽象 类 


分 析 模 型 中 每 个 封装 了 数据 的 实体 类 被 设计 为 一 个 数据 抽象 类 。 一 个 实体 类 保存 了 一 些 
数据 ， 并 且 提 供 了 访问 数据 和 读 写 数 据 的 操作 。 数 据 抽象 类 用 于 封装 数据 结构 ， 因 此 隐藏 了 数 
据 结构 的 内 部 实现 细节 。 操 作 被 设计 为 访 


问 过 程 或 访问 函数 ， 其 内 部 所 定义 的 关于 = 
如 何 操纵 数据 结构 的 细节 也 是 隐藏 的 。 а 


Interaction 


通过 数据 抽象 类 封装 的 属性 信息 应 该 
可 以 从 问题 域 的 静态 模型 ( 在 第 7 章 中 讨 
论 ) 中 获取 。 数 据 抽象 类 的 操作 可 以 通过 
考虑 使 用 数据 抽象 对 象 间接 访问 数据 结构 
的 客户 端 对 象 的 需要 来 确定 。 这 可 以 通过 
分 析 其 他 对 象 访问 数据 抽象 对 象 的 方式 来 
确定 ， 正 如 通信 图 中 所 描述 的 那样 。 这 一 mak 
点 将 通过 下 一 节 中 的 例子 来 说 明 。 Ye | 


数据 抽象 类 示例 


作为 数据 抽象 类 的 一 个 例子 ， 考 虑 
图 14-2a 中 的 分 析 模 型 通信 图 ， 该 图 由 






«user 
interaction» 
: Operator 
Interaction 






у А1: Cash Added 










«entity» 
: ATMCash 





out fivesToDispense, 
out tensToDispense, 
у W1.1: Cash Response out twentiesToDispense) 






«output» 
: CashDispenser 
Interface 


: CashDispenser 
Interface 


a) 分 析 模型 : 通信 图 b) 设计 模型 : 通信 图 


需要 访问 “ATM 现金 ”( ATM Cash ) 数据 
抽象 对 象 的 两 个 对 象 组 成 。“ATM 现金 ” 
对 象 的 属性 在 静态 模型 中 给 出 。“ATM Ж 
金 ” 对 象 保 存 了 由 ATM 吐 钞 器 维护 的 现 
金 总 量 ， 包 括 20 美元 、10 美 元 和 5 美元 
的 现 钞 。 因 此 ， 该 对 象 内 部 包含 分 别 记 录 
5 美元 、10 美元 和 20 美元 现 钞 数量 的 内 部 
变量 。 为 此 ,“ATM 现金 ”类 被 设计 为 封 


«data abstraction» 
ATMCash 
- cashAvailable: Integer = 0 
- fives: Integer = 0 
- tens: Integer = 0 
- twenties: Integer = 0 


+ addCash (in fivesAdded, in tensAdded, in twentiesAdded) 
+ withdrawCash (in cashAmount, out fivesToDispense, out 
tensToDispense, out twenties ToDispense) 





с) 设计 模型 : 类 图 
图 14-2 数据 抽象 类 示例 


装 4 个 内 部 变量 ， 即 cashAvailable 、fives 、tens 、twenties。 这 些 变 量 的 初始 值 都 被 设置 为 0。 [235 
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除了 知道 哪些 消息 将 会 发 送 给 “ATM 现金 ” 对象， 我 们 还 需要 知道 消息 发 送 的 先后 顺 
序 。 因 此 ， 在 分 析 模 型 中 ， 当 “ATM 现金 ”对 象 从 “ 吐 钞 器 接口 ”对 象 收 到 一 个 “现金 提取 
金额 ”的 消息 时 ， 它 需要 计算 为 了 满足 该 请 求 各 种 不 同 面额 的 现 钞 需要 提取 多 少 。 在 分 析 模 
型 中 ,“ATM 现金 ”对 象 在 一 个 响应 消息 Cash Response 中 发 送 这 个 信息 。 

“АТМ 现金 ”对 象 从 “操作 员 交 互 ”( operator interaction) 对 象 接 收 另 一 种 消息 。 现 
实 世界 中 的 ATM 操作 员 向 ATM 吐 钞 器 中 填充 每 种 面额 的 美元 现 钞 。 这 个 信息 需要 保存 在 
“АТМ 现金 ”对 象 中 。 向 取款 机 加 人 现金 后 ， 操 作 员 向 “操作 员 交 互 ” 对 象 确认 此 消息 。 接 
着 ,“ 操 作 员 交互 ”对 象 向 “ATM 现金 ”对 象 发 送 一 条 “增加 现金 ”( Cash Added) 的 消息 ， 
如 图 14-2a 所 示 。 

根据 之 前 的 讨论 ,“ATM 现金 ”类 的 操作 现在 可 以 被 确定 下 来 了 ， 如 图 14-2b 中 的 设计 
模型 通信 图 所 描述 的 那样 。 该 对 象 需要 两 个 操作 :“ 增 加 现金 ”(addCash ) 和 “提取 现金 ” 
(withdrawCash )。“ 提 取现 金 ”操作 有 1 个 输入 参数 cashAmount ( 现金 总 量 ) 和 表示 各 种 面额 
的 现 钞 数 量 的 3 个 输出 参数 fvesToDispense ( 提取 的 5 美元 现 钞 数量 )、tensToDispense ( 提 
取 的 10 美元 现 钞 数量 ) 和 twentiesToDispense ( 提取 的 20 美元 现 钞 数 量 )。 与 之 相对 应 ， 增 
加 现金 操作 有 表示 各 种 面额 的 现 钞 数量 的 3 个 输入 参数 fivesAdded (加 入 的 5 美元 现 钞 数量 )、 
tensAdded (加 入 的 10 美元 现 钞 数量 ) 和 twentiesAdded ( 加 入 的 20 美元 现 钞 数量 )。ATM Ж 
金 类 的 接口 《如 图 14-2c 所 示 ) 由 “增加 现金 ”和 “提取 现金 ”这 两 个 公共 操作 以 及 操作 的 
参数 组 成 ， 描 述 如 下 : 


withdrawCash (in cashAmount, out fivesToDispense, out tensToDispense, out 
twentiesToDispense) 
addCash (in fivesAdded, in tensAdded, in twentiesAdded) 


这 个 类 的 对 象 需要 保持 的 一 个 不 变量 是 可 提取 的 现金 总 量 等 于 5 美元 现 钞 的 总 金额 、10 
美元 现 钞 的 总 金额 和 20 美元 现 钞 的 总 金额 三 者 相 加 之 和 ， 表 示 如 下 : 


cashAvailable = 5 * fives + 10 * tens + 20 * twenties 


没有 充足 的 现金 是 一 个 需要 被 检测 的 错误 ， 这 样 的 错误 状况 通常 被 作为 异常 处 理 。 
14.5 ”状态 机 类 


一 个 状态 机 类 封装 了 一 个 状态 图 中 所 包含 的 信息 。 在 类 设计 的 过 程 中 ， 需 要 对 分 析 模 型 
中 所 确定 的 状态 机 类 进行 设计 。 状 态 机 对 象 所 执行 的 状态 图 被 封装 在 一 个 状态 转换 表 中 。 因 
此 ， 状 态 机 类 隐藏 了 状态 转换 表 的 内 容 ， 并 且 维 护 对 象 的 当前 状态 。 

状态 机 类 提供 了 访问 状态 转换 表 和 改变 对 象 状 态 的 操作 。 具 体 而 言 ， 一 般 会 设计 一 个 或 
多 个 操作 来 处 理 导致 状态 改变 的 输入 事件 。 设 计 状 态 机 类 操作 的 一 种 方法 是 为 每 个 输入 事件 
设计 一 个 操作 ， 这 意味 着 每 个 状态 机 类 都 是 为 一 个 特定 的 状态 图 设计 的 。 然 而 ， 一 个 更 好 的 
办 法 是 设计 一 个 可 以 复 用 的 状态 机 类 。 

一 个 可 复 用 的 状态 机 类 与 之 前 一 样 隐藏 了 状态 转换 图 的 内 容 ， 但 是 会 提供 两 个 非特 定 应 
用 的 可 复 用 的 操作 processEvent 和 currentState。processEvent 操作 是 当 有 新 的 事件 要 处 理 的 时 
候 被 调用 ， 并 且 将 传人 的 新 事件 作为 一 个 输入 参数 。currentState 操作 是 可 选 的 ， 它 返回 ATM 
控制 的 状态 。 该 操作 仅 当 状态 机 类 的 客户 端 需要 知道 状态 机 对 象 的 当前 状态 时 才 需 要 。 这 两 
个 操作 的 定义 如 下 : 
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processEvent (in event, out action) 

currentState (): State 

当 被 调用 来 处 理 一 个 新 事件 时 ，processEvent 操作 查找 状态 转换 表 来 确定 这 个 事件 的 影 
响 ， 考 虑 状态 机 的 当前 状态 和 必须 满足 的 所 有 条 件 。 通 过 状态 转换 表 确 定 新 状态 是 什么 〈 如 
果 发 生 状 态 转移 的 话 ) 以 及 需要 执行 什么 动作 。 接 下 来 ，processEvent 操作 改变 对 象 的 状态 ， 
并 且 返 回 需要 执行 的 动作 作为 输出 参数 。 

这 样 的 状态 机 类 是 一 种 可 复 用 的 类 ， 因 为 它 可 以 用 来 封装 任何 状态 转换 图 。 表 中 的 内 容 
是 依赖 于 特定 应 用 的 ， 并 且 在 状态 机 类 被 实例 化 和 /或 初始 化 时 定义 。 状 态 机 当前 状态 的 初 
始 值 ( 被 设 定 为 ATM 初始 状态 ) 也 是 在 初始 化 时 定义 。 a 

“银行 系统 ”中 一 个 状态 机 类 的 例子 是 ATM State Machine 
状态 机 类 ， 如 图 14-3 所 示 。 这 个 类 封装 了 ATM 状态 转换 表 


+ processEvent (in event, out action) 
(从 ATM 状态 图 中 映射 得 到 ， 如 第 10 章 和 第 21 章 所 述 )， 并 且 


提供 了 processEvent 和 currentState 操作 。 图 14-3 ”状态 机 控制 类 示例 


146 ”图 形 用 户 交 互 类 


一 个 图 形 用 户 交 互 (GUI) 类 向 其 他 类 隐藏 了 与 用 户 界 面相 关 的 细节 。 在 一 个 特定 的 应 
用 中 ， 用 户 界面 可 能 是 一 个 简单 的 命令 行 界面 或 者 一 个 复杂 的 图 形 用 户 交互 界面 。 命 令 行 界 
面 通常 可 以 由 一 个 用 户 交 互 类 人 处理 。 然 而 ， 图 形 用 户 界面 的 设计 通常 需要 设计 多 个 GUI 类 。 
底层 的 GUI 类 ， 例 如 窗口 、 菜 单 、 按 钮 和 对 话 框 等 通常 都 保存 在 用 户 界 面 构件 库 中 。 更 高 层 
次 上 的 复合 用 户 交 互 类 (被 动 类 或 主动 类 ， 如 第 18 章 所 述 ) 通常 被 设计 为 包含 这 些 较 低 层次 
的 GUI 类 的 复合 类 。 

在 分 析 模 型 中 ， 重 点 应 该 放 在 识别 复合 用 户 交 互 类 并 捕捉 需要 用 户 输入 的 信息 以 及 需要 
向 用 户 显 示 的 信息 。 各 个 GUI 屏幕 画面 也 可 以 被 设计 成 分 析 模 型 的 一 部 分 。 在 针对 基于 GUI 
的 应 用 的 设计 模型 中 ， 每 一 个 GUI 屏幕 画面 所 需要 的 GUI 类 都 需要 被 设计 。 

银行 应 用 中 用 户 交 互 类 的 例子 是 在 设计 GUI 中 使 用 的 类 。 这 些 GUI 类 是 针对 与 客户 交 
互 的 每 一 个 窗口 所 设计 的 (图 14-4): 主 “ 菜 单 窗 口 ”( Menu Window ), “PIN ЯН” (РМ 
Window )、“ 取 款 窗 口 ”( Withdraw Window )、“ 转 账 窗 口 ”( Transfer Window )、“ 查 询 窗口 ” 
( Query Window ) 和 “提示 窗口 ”( Prompt Window ) 类 。 一 个 GUI 类 拥有 窗口 显示 的 操作 ， 
并 且 通 过 窗口 与 客户 交互 。 每 个 类 都 有 一 个 清空 操作 以 使 得 屏幕 被 清空 ( clear )， 并 且 至 少 
拥有 一 个 与 所 提供 的 输出 功能 相关 的 操作 ( 针对 “PIN 窗口 ”类 的 displayPINWindow、 针 对 
“取款 窗口 ”类 的 displayWithdrawalWindow、 针 对 “转账 窗口 ”类 的 displayTransferWindow 、 
针对 “查询 窗口 ”类 的 displayQueryWindow， 以 及 针对 主 菜单 的 displayMenu 操作 )。 对 于 每 
个 显示 窗口 ， 其 中 的 显示 操作 都 会 向 用 户 输出 提示 信息 ， 然 后 接收 用 户 的 输入 ， 并 将 此 输入 
信息 作为 该 显示 操作 的 输出 参数 返回 。 例 如 ， 图 14-4 描述 了 “菜单 窗口 ”GUI 类 ， 该 类 提供 
了 操作 displayMenu ( out selection ), displayMenu 操作 被 调用 后 会 为 客户 输出 一 个 带 有 菜单 
选项 的 提示 : 取款 、 查 询 或 转账 。 客 户 选择 一 个 选项 ( 例如 取款 ), displayMenu 操作 将 该 选 
项 作为 输出 参数 selection 的 内 容 返 回 。 在 “取款 窗口 ”类 中 displayWithdrawalWindow ( out 
accountNumber, out amount ) 操作 提示 用 户 输入 账户 号 码 和 取款 金额 。 用 户 输入 这 些 数据 后 ， 
账户 号 码 和 取款 金额 将 作为 该 操作 的 输出 参数 返回 。 
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«ОШ» «ОШ» «ОШ» 
PINWindow MenuWindow WithdrawalWindow 


+ clear() + clear() + clear() 

+ displayPINWindow (out PIN) + displayMenu (out selection) + displayWithdrawalWindow 
(out accountNumber, out 
amount) 


«GUl» «Си!» «ОШ» 
QueryWindow TransferWindow PromptWindow 


+ clear() + clear() + clear() 
+ displayQueryWindow (out + displayTransferWindow (out + displayPrompt (in 
accountNumber) fromAccountNumber, out promptText) 
toAccountNumber, out 
amount) 


Я 14-4 图 形 用 户 交互 (GUI) 类 示例 


除 此 之 外 ， 还 有 一 个 向 客户 显示 提示 和 信息 消息 的 小 窗口 的 操作 ， 该 窗口 不 需要 任何 客户 
输入 。 该 显示 操作 的 输入 参数 是 需要 显示 的 提示 信息 或 消息 。 图 14-4 描述 了 提示 窗口 (Prompt 
Window ) 类 ， 该 类 拥有 一 个 清空 提示 窗口 的 操作 和 displayPrompt ( in promptText ) 操作 。 


147 ”业务 逻辑 类 


业务 逻辑 类 定义 了 处 理 客户 端 请 求 的 决策 以 及 特定 业务 的 应 用 逻辑 ， 其 目的 是 将 可 能 会 
相互 独立 变化 的 业务 规则 封装 到 不 同 的 业务 逻辑 类 中 。 通 常 一 个 业务 逻辑 对 象 会 在 其 执行 过 
程 中 访问 多 个 不 同 的 实体 对 象 。 

业务 逻辑 类 的 一 个 例子 是 “取款 交易 管理 器 ”( Withdrawal Transaction Manager ) Ж ( 见 
图 14-5 )， 该 类 封装 了 处 理 ATM 取款 请 求 的 规则 。 该 类 拥有 “初始 化 ”( initialize )、“ 取 款 ” 
(withdraw ) “ЖТА” (confirm) 和 “终止 ”(abort ) 操作 -。“ 初 始 化 操作 ”在 初始 化 阶段 被 调 
用 ;“ 取 款 ” 操 作 在 从 客户 账户 取款 的 时 候 被 调用 ; “确认 ” 操 作 在 确认 取款 交易 成 功 完成 时 
调用 ;“ 终 止 ”操作 在 交易 未 成 功 完 成 时 调用 ( 例如， 如果 现金 没有 从 АТМ 机 中 取出 )。 这 些 
操作 是 通过 仔细 分 析 “ 银 行 服务 ”分 析 模 型 通信 图 ( 如 图 14-5a ) 和 标识 消息 内 容 的 消息 序列 
描述 (参考 第 19 章 ) 确定 的 。 在 此 基础 上 ， 如 图 14-5b 所 示 的 设计 模型 通信 图 和 图 14-5c 所 
示 的 类 图 也 可 以 被 确定 下 来 。 


14.8 设计 中 的 继承 


继承 可 以 用 在 设计 两 个 相似 却 并 非 完 全 相同 的 类 ( 换 句 话说， 这 些 类 共享 很 多 但 不 是 所 
有 的 特性 ) 的 时 候 。 在 体系 结构 设计 中 ， 设 计 类 时 应 当 考 虑 继承 ， 以 使 得 代码 共享 和 代码 的 
适应 性 可 以 在 详细 设计 和 编码 中 得 到 充分 利用 。 继 承 也 可 以 用 于 以 维护 或 复 用 为 目的 的 设计 
调整 的 时 候 。 按 照 这 种 方式 使 用 ， 最 大 的 好 处 来 自 于 将 继承 作为 一 个 增 量 的 修改 机 制 。 


14.8.1 类 继承 








类 层次 ( 也 被 称 为 泛 化 / 特 化 层次 和 继承 层次 ) 可 以 按照 自 顶 向 下 、 自 底 向 上 或 二 者 相 结合 
的 方式 来 设计 。 使 用 自 项 向 下 的 方法 时 ， 一 个 类 被 设计 为 捕捉 一 组 类 的 总 体 特性 。 将 这 种 类 特 化 
为 多 个 不 同 的 子 类 是 对 这 些 子 类 之 间 的 差异 性 进行 区 分 。 如 果 使 用 自 底 向 上 的 方法 ， 那 么 初始 的 
设计 可 以 包含 具有 一 些 共同 特性 ( 操作 和 /或 属性 ) 以 及 一 些 不 同 特性 的 一 组 类 。 在 这 种 情况 下 ， 
可 以 将 共同 的 特性 泛 化 为 一 个 超 类 ， 而 这 些 共同 的 属性 和 /或 操作 将 被 不 同 的 子 类 共同 继承 。 
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需要 注意 的 是 ， 在 使 用 了 继承 机 制 的 设计 中 ， 父 类 的 内 部 对 于 子 类 是 可 见 的 。 由 于 这 个 

‚| 原因 ， 通 过 子 类 进行 设计 和 复 用 被 看 作 是 白 盒 复 用 。 因 此 ， 继 承 打 破 了 封装 〈 即 信息 隐藏 ) 
240] ”的 概念 。 子 类 的 实现 与 父 类 的 实现 是 绑 定 的 ， 这 样 可 能 会 导致 具有 深度 继承 层次 的 波纹 效应 
问题 。 因 此 ， 一 个 在 继承 结构 中 较 高 层次 上 的 类 中 的 一 个 错误 会 被 继承 结构 中 所 有 较 低 层次 
上 的 子 类 所 继承 。 由 于 这 个 原因 ， 一 个 明智 的 作法 是 限制 类 继承 层次 的 深度 。 


14.8.2 ”抽象 类 


抽象 类 是 没有 实例 的 类 。 由 于 抽象 类 没有 实例 ， 因 此 可 以 被 用 作 创 建 子 类 的 模板 ， 
而 不 是 用 作 创 建 对象 的 模板 。 因 此 ， 抽 象 类 只 能 用 来 作为 一 个 超 类 并 且 为 其 子 类 定义 公 
共 接 口 。 抽 象 操作 是 在 抽象 类 中 声明 但 没有 实现 的 操作 。 一 个 抽象 类 必须 至 少 包 含 一 个 
抽象 操作 。 

抽象 类 将 其 所 有 或 部 分 操作 实现 推迟 到 子 类 所 定义 的 操作 中 去 考虑 。 考 虑 由 抽象 操作 提 
供 的 接口 ， 一 个 子 类 可 以 定义 这 个 操作 的 实现 。 相 同 抽象 类 的 不 同 子 类 可 以 为 相同 的 抽象 操 
作 定义 不 同 的 实现 。 因 此 ， 一 个 抽象 类 以 抽象 操作 的 形式 定义 接口 。 子 类 定义 了 抽象 操作 的 
实现 ， 并 且 可 以 通过 增加 其 他 操作 来 扩展 接口 。 

一 些 操作 可 以 在 抽象 类 中 实现 ， 尤 其 是 在 其 部 分 或 全 部 子 类 都 需要 使 用 相同 实现 的 情况 
下 。 此 外 ， 抽 和 象 类 也 可 以 定义 一 个 操作 的 缺 省 实现 。 子 类 也 可 以 选择 通过 为 相同 的 操作 提供 
不 同 的 实现 来 重 写 父 类 定义 的 操作 。 这 种 方法 可 以 在 一 个 特定 的 子 类 必须 处 理 需 要 该 操作 的 
不 同 实现 的 特殊 情况 时 使 用 。 


14.8.3 ”抽象 类 和 子 类 示例 


“银行 系统 ”中 抽象 类 和 子 类 的 一 个 例子 是 该 系统 所 提供 的 不 同类 型 的 账户 。“ 银 行 系 
统 ” 中 最 初 提供 的 是 支票 账户 和 储蓄 账户 ， 虽 然后 面 还 会 增加 其 他 类 型 的 账户 ( 例如 货币 市 
场 账 户 )。 设 计 的 起 点 是 在 静态 建 模 过 程 中 所 开发 的 泛 化 / 特 化 类 图 (图 14-6 )， 如 第 7 章 所 
述 ， 其 中 描述 了 “账户 ”( Account ) 超 类 和 两 个 子 类 ， 即 “支票 账户 ”( Checking Account ) 
和 “储蓄 账户 ”( Savings Account )。 下 一 步 是 设计 类 的 操作 。 


accountNumber: Integer 
balance: Real 
А 

















CheckingAccount SavingsAccount 


图 14-6 ”抽象 超 类 和 子 类 示例 : 分 析 模 型 


“账户 ”类 被 设计 为 一 个 抽象 类 ， 其 中 封装 了 所 有 账户 类 型 都 需要 的 两 个 泛 化 的 属性 : 
“账户 号 ”( accountNumber ) 和 “余额 ”( balance )。 由 于 需要 能 够 开设 和 关闭 账户 、 读 取 账 户 
余额 、 记 入 贷方 和 记 人 借方 ， 因 此 为 “账户 ”类 确定 了 以 下 这 些 泛 化 操作 : 

® open (accountNumber : Integer) 

® close() 
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• readBalance ( ) : Real 

è credit (amount : Real) 

e debit (amount : Real) 

“银行 系统 ”最 初 只 需要 处 理 两 种 类 型 的 账户 : 支票 账户 和 储蓄 账户 。“ 账 户 ” 相 关 的 类 
很 适合 使 用 继承 机 制 ， 包 括 一 个 泛 化 的 账户 超 类 和 两 个 的 特 化 的 子 类 ( 支票 账户 类 和 储蓄 账 
户 类 )。 在 这 个 阶段 ,我 们 需要 问 以 下 这 些 问题 : 账户 超 类 应 该 拥有 哪些 泛 化 的 操作 和 属性 ? 
支票 账户 和 储蓄 账户 子 类 应 该 拥有 哪些 特 化 的 操作 和 属性 ? 账户 类 应 该 是 个 抽象 类 吗 ， 即 哪 
些 操 作 ( 如 果 有 的 话 ) 应 该 是 抽象 的 ? 

在 能 够 回答 这 些 问 题 之 前 ， 我 们 需要 知道 支票 账户 和 储蓄 账户 在 哪些 方面 相似 ， 哪 些 方 
面 不 同 。 首 先 考虑 属性 。 很 明显 支票 账户 和 储蓄 账户 都 需要 “账户 号 ”和 “余额 ”属性 ， 因 
此 这 两 个 属性 可 以 成 为 泛 化 属性 并 使 得 它们 可 以 被 “支票 账户 ”和 “储蓄 账户 ” 子 类 继承 。 
支票 账户 的 一 个 需求 是 需要 知道 账户 中 最 近 一 笔 存 款 的 金额 ， 因 此 “支票 账户 ”需要 一 个 称 
为 lastDepositAmount 的 特 化 属性 。 另 一 方面 ， 在 该 银行 中 ,储蓄 账 户 会 产生 利息 而 支票 账户 
则 不 会 。 我 们 需要 知道 一 个 储蓄 账户 的 累积 利息 ， 因 此 cumulativelnterest 作为 “储蓄 账户 ” 
子 类 的 一 个 属性 进行 了 声明 。 此 外 ， 银 行 允许 每 个 储蓄 账户 每 个 月 可 以 免费 取款 3 次， 因此 
debitCount 也 被 作为 “储蓄 账户 ” 子 类 的 一 个 属性 进行 了 声明 。 

ЖУК, “储蓄 账户 ”类 中 还 声明 了 两 个 静态 类 属性 ， 这 些 属性 对 于 整个 类 只 有 一 个 唯一 的 
值 存在 ， 这 个 值 可 以 被 该 类 所 有 的 对 象 访问 。 这 两 个 静态 属性 是 maxFreeDebits ( 免费 取款 的 
最 大 次 数 ， 初 始 化 为 3 ) 和 bankCharge ( 超出 免费 取款 最 大 次 数 后 每 笔 取 款 的 “银行 手续 费 ”， 
初始 化 为 2.5 美元 )。 

“支票 账户 ”和 “储蓄 账户 ”都 需要 与 “账户 ”类 相同 的 操作 ， 即 “开设 账户 ”( open )、 
“关闭 账户 ”( close )、“ 读 取 余 额 ”( readBalance )、“ 存 款 ”( credit ) 和 “取款 ”( debit )。 这 些 
操作 的 接口 被 定义 在 “账户 ” 超 类 中 ， 因 此 两 个 子 类 将 从 “账户 ”类 中 继承 同样 的 接口 。“ 开 
设 账 户 ” 和 “关闭 账户 ”操作 在 支票 账户 和 储蓄 账户 中 的 执行 方式 相同 ， 因 此 这 些 操 作 的 实 
现 可 以 在 “账户 ”中 定义 并 且 被 子 类 继承 。“ 存 款 ” 和 “取款 ”操作 在 支票 账户 和 储蓄 账户 中 
的 处 理 方式 不 同 ， 因 此 这 两 个 操作 都 被 设计 为 具有 超 类 中 特 化 的 操作 接口 的 抽象 操作 ， 但 是 
这 两 个 操作 的 实现 将 被 推迟 到 子 类 中 定义 。 

对 于 “支票 账户 ” 子 类 而 言 ,“ 取 款 ” 操 作 的 实现 需要 从 “余额 ”属性 中 扣 减 掉 取 款 “ 金 
额 ”( amount ).“ 存 款 ” 操 作 的 实现 需要 在 “余额 ”属性 上 增加 存款 “金额 ”， 然 后 将 “最 
近 一 笔 存 款 金额 ”( lastDepositAmount ) 属性 的 值 设置 为 本 次 存款 的 “金额 "*。 对 于 “储蓄 账 
户 ” 子 类 而 言 ,，“ 存 款 ” 操 作 的 实现 需要 在 “余额 ”属性 上 增加 存款 “金额 "。“ 取 款 ” 操 作 的 
实现 除了 从 储蓄 账户 的 “余额 ”中 扣 减 掉 取款 金额 之 外 ， 还 需要 对 “取款 次 数 ” 加 一 并 是 为 
每 笔 超 出 “免费 取款 的 最 大 次 数 ” 的 取款 扣除 “银行 手续 费 ”"。 此 外 ,“ 储 蓄 账 户 ” 类 还 需要 
一 个 操作 clearDebitCount 来 清空 取款 次 数 ， 用 来 在 每 个 月 的 月 底 重 新 将 “取款 次 数 ”( debit 
Count) 重 置 为 0。 

初 看 之 下 ， 支 票 账户 和 储蓄 账户 的 :“ 读 取 ”( read ) 账户 操作 似乎 是 完全 一 样 的 ， 然 而 
仔细 检查 后 发 现 并 非 如 此 。 当 我 们 读 取 支票 账户 时 ， 和 希望 得 到 账户 余额 和 最 近 一 笔 存 款 金 额 。 
当 我 们 读 取 储蓄 账户 时 ， 希 望 得 到 账户 余额 和 累计 利息 。 解 决 方案 是 设置 多 个 读 取 操 作 。 其 
中 ， 泛 化 的 读 取 操 作 readBalance 用 于 读 取 账户 余额 ， 该 操作 被 “支票 账户 ”和 “储蓄 账户 ” 
类 继承 。 一 个 特 化 的 读 取 操作 readCumulativelnterest 读 取 累 计 利息 ) 被 加 入 到 “储蓄 账户 ” 
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子 类 中 ; 另 一 个 特 化 的 读 取 操 作 readLastDepositAmount ( 读 取 最 近 一 笔 存 款 金 额 ) 被 加 入 到 
“支票 账户 ” 子 类 中 。 

“账户 ”相关 类 的 泛 化 / 特 化 层次 的 设计 在 图 14-7 中 进行 了 描述 并 将 在 后 面 详细 介绍 。 
该 图 使 用 了 UML 中 用 斜体 描述 抽象 类 名 称 的 惯例 。 


«entity» 
Account {abstract} 
# accountNumber : Integer 
# balance : Real = 0 


+ open (accountNumber : Integer) 
# credit (amount : Real) {abstract} 
# debit (amount : Real) {abstract} 
+ readBalance () : Real 
+ close () 















«entity» 
CheckingAccount 
- lastDepositAmount : Real = 0 


+ credit (amount : Роа) 
+ debit (amount : Rea 
пре р la ity Real 


«entity» 
SavingsAccount 


- ситија ме пеге! : Real = 0 
- debitCount : Integer = 0 








+ addinterest (interestRate : Real) 
+ readCumulativelnterest () : Rea 





图 14-7 抽象 超 类 和 子 类 示例 : 设计 模型 


14.8.4 抽象 超 类 和 子 类 设计 


1. 账 户 抽象 超 类 的 设计 
• 属性 : 
e 定义 了 属性 “账户 号 ”(accountNumber ) 和 “余额 ”(balance )。 这 两 个 属性 在 “ 账 
户 ” 超 类 中 被 声明 为 受 保护 ( protected )， 因 此 它们 对 于 子 类 是 可 见 的 。 
• (Е: 
ө 定义 “开设 账户 ”( open ) “ИР!” (close) 和 “ 读 取 余额 ”(readBalance ) 操 
作 的 规约 和 实现 。 
© 定义 抽象 操作 “存款 ”( credit ) 和 “取款 ”( debit ) 的 规约 。 
2. 支票 账户 子 类 的 设计 
• 属性 : 
o 继承 了 属性 accountNumber 和 balance. 
o 增加 属性 “最 近 一 笔 存 款 金 额 ”( lastDepositAmount )。 
o (Е: 
e 继承 了 操作 open, close 和 readBalance 的 规约 和 实现 。 
° 继承 了 抽象 操作 credit 的 规约 ; 将 该 操作 的 实现 定义 为 向 账户 “余额 ”中 增加 存款 
“金额 ”并 将 “最 近 一 笔 存 款 金额 ”设置 为 本 次 存款 “人 金额”。 
o 继承 了 抽象 操作 debit 的 规约 ; 将 该 操作 的 实现 定义 为 从 账户 “余额 ”中 减 去 取款 “金额 ”。 
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o 增加 操作 “ 读 取 最 近 一 笔 存款 金额 ”( readLastDepositAmount(): Real )。 
3. 储蓄 账户 子 类 的 设计 
• 属性 

ө 继承 了 属性 accountNumber 和 balance, 

ө 增加 属性 “累计 利息 ”( cumulativeInterest ) 和 “取款 次 数 ”( debitCount )。 

e 增加 静态 类 属性 “最 大 免费 取款 次 数 ”( maxFreeDebits ) 和 “银行 手续 费 ” 
(bankCharge )。 静 态 属性 在 UML 中 用 下 划 线 表示 ， 如 图 13-9 所 示 。 

• 操作 : 

o 继承 了 操作 open, close 和 readBalance 的 规约 和 实现 。 

o 继承 了 抽象 操作 debit 的 规约 ; 将 该 操作 的 实现 定义 为 从 账户 “余额 ”中 减 去 取款 
“金额 ”， 将 “取款 次 数 ” 加 一 ， 并 且 如 果 此 次 取款 已 经 超出 了 “最 大 免费 取款 次 
数 ”的话 ， 还 需要 从 账户 “余额 ”中 扣 减 一 笔 “银行 手续 费 "。 

o 继承 了 抽象 操作 credit 的 规约 ; 将 该 操作 的 实现 定义 为 向 账户 “余额 ”中 增加 存款 
“金额 ”。 

e 增加 下 列 操作 : 
> addInterest (interestRate : Real)， 每 天 增加 利息 。 
> readCumulativelnterest () : Real， 返 回 储蓄 账户 的 累计 利息 。 
> clearDebitCount ()， 在 每 个 月 月 底 重 新 将 取款 次 数 重 置 为 0。 


149 ”类 接口 规约 


类 接口 规约 定义 了 信息 隐藏 类 的 接口 ， 包 括 一 个 类 所 提供 的 操作 的 规约 ， 具体 包括 : 
• 信息 隐藏 类 所 隐藏 的 信息 : 例如 数据 抽象 类 所 封装 的 数据 结构 。 
© 用 来 设计 该 类 的 类 组 织 准则 。 
ө 定义 类 时 所 作 的 假设 : 例如 一 个 操作 是 否 需 要 在 男 一 个 操作 之 前 调用 。 
ө 预期 的 变化 。 这 是 为 了 鼓励 对 于 设计 变化 的 考虑 。 
o HA ( 如 果 有 的 话 ) 
o 继承 的 操作 ( 如 果 有 的 话 ) 
© 该 类 所 提供 的 操作 。 对 于 每 个 操作 需要 定义 : 
• 所 执行 的 功能 
e 前 置 条 件 〈 当 该 操作 被 调用 时 必须 成 立 的 条 件 ) 
° 后 置 条 件 〈 当 该 操作 完成 时 必须 成 立 的 条 件 ) 
о 不 变量 ( 在 任何 时 刻 都 必须 成 立 的 条 件 ， 包 括 操作 执行 前 、 执 行 时 和 执行 后 ) 
• 输入 参数 
。 输出 参数 
° 所 使 用 的 其 他 类 的 操作 


类 接口 规约 示例 


这 里 给 出 一 个 信息 隐藏 类 的 类 接口 规约 的 例子 。 这 个 支票 账户 类 的 例子 在 图 14-7 中 进行 
了 描述 ， 并 在 14.8 节 中 进行 了 介绍 。 
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信息 隐藏 类 : 支票 账户 ( CheckingAccount ) 
信息 隐藏 : 封装 支票 账户 的 属性 和 它们 的 当前 值 
类 组 织 准则 : 数据 抽象 类 
假设 : 支票 账户 没有 利息 
预期 的 变化 : 支票 账户 可 能 会 被 允许 赚 取 利息 
超 类 :“ 账 户 ” 
继承 的 操作 :“ 开 设 账 户 ”(open )、“ 存 款 ”(credit) “HA” (debit) “ERRA” 
(readBalance ) “Ж Я ЖР” (close ) 
提供 的 操作 : 
1. credit (in amount : Real) 
功能 : 在 当前 账户 余额 基础 上 增加 本 次 存款 金额 ， 并 且 将 其 保存 为 最 近 一 笔 
存款 金额 。 
前 置 条 件 : 账户 已 创建 。 
后 置 条 件 : 支票 账户 已 存 入 相应 金额 。 
输入 参数 : 金额 一 一 将 被 增加 到 账户 上 的 资金 。 
使 用 的 操作 : 无 。 
2. debit (in amount : Real) 
功能 : 从 当前 账户 余额 中 扣 减 指定 的 金额 。 
前 置 条 件 : 账户 已 创建 。 
АВА: 支票 账户 被 取出 相应 金额 。 
输入 参数 : 金额 一 一 将 从 账户 中 扣 减 的 资金 。 
输出 参数 : 无 
使 用 的 操作 : 无 
3. readLastDepositAmount (): Real 
功能 : 返回 最 近 一 次 存 入 当前 账户 的 金额 。 
前 置 条 件 : 账户 存在 。 
不 变量 : 账户 属性 的 值 保 持 未 变 。 
后 置 条 件 : 最 近 一 次 存 入 当前 账户 的 金额 被 读 取 。 
输入 参数 : 无 
输出 参数 : 最 近 一 次 存 入 当前 账户 的 金额 
使 用 的 操作 : 无 





14.10 ”信息 隐藏 类 的 详细 设计 


在 信息 隐藏 类 的 详细 设计 过 程 中 ， 需 要 确定 每 个 操作 的 内 部 算法 设计 。 操 作 内 部 可 以 
用 伪 代 码 ( 也 被 称 为 结构 化 英语 ) 来 描述 ， 其 中 蕴含 的 思想 是 算法 设计 是 独立 于 编程 语言 
的 ,但 是 可 以 很 容易 地 映射 到 特定 的 实现 语言 上 。 伪 代码 使 用 结构 化 编程 结构 ( 例如 If-Then- 
Else、 循 环 和 case 语句 ) 表示 决策 语句 ， 使 用 英语 来 描述 顺序 语句 。 接 下 来 将 会 介绍 一 个 使 用 
伪 代 码 描述 的 账户 类 中 的 算法 设计 的 例子 。 
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14.10.1 账户 抽象 超 类 的 详细 设计 


e 属性 : accountNumber、balance 
• 操作 : 
® open (in accountNumber : Integer) 
begin; 
create new account; 
assign accountNumber; 
set balance to zero; 
end. 
è close () 
begin; close the account; end. 
• readBalance () : Real 
begin; return value of balance; end. 
® credit (in amount : Real) 
推迟 到 子 类 实现 。 
e debit (in amount : Real) 


推迟 到 子 类 实现 。 
14.102 ”支票 账户 子 类 的 详细 设计 
e 属性 : 


e ЖЖ: accountNumber, balance 
• 声明 : lastDepositAmount 
• 操作 : 
• 继承 规约 和 实现 : open、close、readBalance 
© 继承 规约 并 定义 实现 : 
credit(in amount : Real); 
begin; 
Add amount to balance; 
Set lastDepositAmount equal to amount; 
end. 
o 继承 规约 并 定义 实现 : 


debit (in amount : Real); 


begin; 
Deduct amount from balance; 
end. 
• 增加 操作 : 
readLastDepositAmount () : Real 
begin; 


return value of lastDepositAmount; 
end. 
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14.10.3 ”储蓄 账户 子 类 的 详细 设计 
• 属性 : 


ө 继承 : accountNumber, balance 
e 声明 : cumulativeInterest、debitCount 
е 声明 静态 类 属性 : maxFreeDebits bankCharge 
• 操作 : 
247 o 继承 规约 和 实现 : open, close, readBalance 
° 继承 规约 并 重新 定义 实现 : 
debit (in amount : Real); 
begin; 
Deduct amount from balance; 
Increment debitCount; 
if maxFreeDebits > debitCount 
then deduct bankCharge from balance; 
end. 
继承 规约 并 重新 定义 实现 : 


credit(in amount : Real); 


begin; add amount to balance; end. 
声明 的 操作 : 


addInterest (interestRate : Real) 


begin; 

Compute dailyInterest = balance * interestRate; 

Add dailyInterest to cumulativelnterest and to balance; 
end. 


readCumulativelnterest () : Real 
begin; return value of cumulativelnterest; end. 
clearDebitCount (), 


begin; Reset debitCount to zero; end. 


14.11 多 态 和 动态 绑 定 


多 态 (polymorphism ) 在 希腊 语 中 的 意思 是 “多 种 形态 ”。 在 面向 对 象 设计 中 ， 多 态 用 来 
表示 不 同 的 类 可 以 拥有 相同 的 操作 名 。 每 个 类 中 操作 的 规约 都 是 相同 的 ， 然 而 这 些 类 可 以 以 
不 同 的 方式 实现 这 些 同名 的 操作 ， 这 使 得 拥有 相同 接口 的 对 象 可 以 在 运行 时 相互 蔡 换 。 

动态 绑 定 与 多 态 一 起 使 用 ， 其 作用 是 在 运行 时 将 一 个 对 象 的 请 求 与 该 对 象 的 具体 操作 关 
联 起 来 。 如 果 使 用 编译 时 绑 定 机 制 〈 过 程式 语言 中 所 使 用 的 典型 绑 定 形式 )， 请 求 与 操作 之 间 
的 关联 是 在 编译 时 完成 的 并 且 不 能 在 运行 时 改变 。 动 态 绑 定 意味 着 请 求 与 对 象 操作 的 绑 定 是 
在 运行 时 完成 的 ， 并 且 可 以 由 一 种 调用 变 为 另 一 种 。 从 请 求 者 的 角度 来 看 ， 一 个 变量 可 以 在 

不 同时 候 引 用 不 同类 的 对 象 ， 并 且 在 这 些 不 同 的 对 象 上 调用 相同 名 字 的 操作 。 
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多 态 和 动态 绑 定 示例 
现在 考虑 基于 这 些 类 的 实例 化 对 象 ， 以 及 使 用 多 态 和 动态 绑 定 的 一 个 例子 : 


begin 

private anAccount: Account; 

Prompt customer for account type and withdrawal amount 
if customer responds checking 


then - assign customer's checking account to anAccount 
anAccount := customerCheckingAccount; 


elseif customer responds savings 


then - assign customer's savings account to anAccount 
anAccount := customerSavingsAccount; 
endif; 


— debit an Account, which is a checking or savings account 
anAccount.debit (amount); 


end; 


在 这 个 例子 中 ， 如 果 账 户 的 类 型 是 支票 账户 ， 那 么 anAccount 对 象 被 赋值 为 “支票 账户 ” 
对 象 。 执 行 anAccount.debit 会 调用 “支票 账户 ”对 象 的 debit 操作 。 男 一 方面 ， 如 果 账 户 的 类 
型 是 储蓄 账户 ， 那 么 执行 anAccount.debit 会 调用 “储蓄 账户 ”对 象 的 debit E. MEIKA I 
执行 的 debit 操作 会 比 支 票 账户 的 debit 操作 做 更 多 的 事情 ， 因 为 如 果 取 款 次 数 超过 最 大 免费 
取款 次 数 的 话 ， 储 蓄 账 户 的 debit 操作 会 收取 额外 的 银行 手续 费 。 

需要 注意 的 是 “支票 账户 ”类 型 或 者 “储蓄 账户 ”类 型 的 对 象 可 以 被 赋值 给 “账户 ”类 
型 的 对 象 ， 但 是 反 过 来 不 行 。 这 是 因为 每 个 “支票 账户 ” 子 类 的 对 象 都 是 一 个 “账户 ” 超 类 
的 对 象 ， 每 个 “储蓄 账户 ” 子 类 的 对 象 都 是 一 个 “账户 ” 超 类 的 对 象 。 然 而 ， 反 过 来 是 不 成 
立 的 ， 因 为 并 不 是 每 个 账户 对 象 都 是 一 个 支票 账户 一 一 它 可 能 是 个 储蓄 账户 ! 





14.12 Java 中 类 的 实现 


本 节 介 绍 一 个 在 Java 中 实现 类 的 例子 ， 其 中 的 类 操作 实现 为 Java 方法 。 考 虑 图 14-2 中 
描述 的 以 及 14.4 节 中 介绍 的 АТМСазћ 类 。 如 下 所 示 ， 在 公共 类 名 声明 之 后 是 私有 变量 的 声 
AA, 包括 可 用 现金 金额 以 及 5 美元 、10 美元 和 20 美元 现 钞 的 数量 ， 所 有 这 些 变量 都 被 初始 
化 为 0。 接 下 来 是 公共 方法 的 声明 ， 包 括 “ 增 加 现金 ”和 “提取 现金 ”。 

“增加 现金 ”( addCash ) 方法 拥有 三 个 整 型 输入 参数 ， 即 需要 增加 的 5 美元 、10 美元 和 
20 美元 现 钞 的 数量 。 在 该 方法 的 实现 中 ， 所 添加 的 每 种 面额 的 现 钞 数量 被 加 到 АТМ 机 中 现 
有 的 现 钞 数量 中 。 接 着 ,“ 可 用 现金 ”( cashAvailable ) 金额 的 值 通过 将 各 种 面额 现 钞 的 金额 相 
加 来 计算 。 

在 “提取 现金 ”( withdrawCash ) 方法 中 ， 期 望 提取 的 金额 是 第 一 个 参数 cashAmount, 
第 二 个 参数 是 所 返回 的 表示 分 别提 取 5 美元 、10 美元 和 20 美元 现 钞 数量 的 整 型 数组 。 
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public class ATMCash { 

private int cashAvailable = 0; 
int fives = 0; 
int tens = 0; 
int twenties = 0; 

public void addCash(int fivesAdded, int tensAdded, int twentiesAdded) { 
// increment the number of bills of each denomination 
fives = fives + fivesAdded; 
tens = tens + tensAdded; 
twenties = twenties + twentiesAdded; 
// set the total cash in the ATM 
cashAvailable = 5 * fives + 10 * tens + 20 * twenties; 


} 

public int withdrawCash(int cashAmount, int [] bills) {} 

// given the cash amount to withdraw, return the number of bills of 
each denomination 


14.13 АЖ 


本 章 介绍 了 使 用 信息 隐藏 、 类 和 继承 思想 的 面向 对 象 软件 体系 结构 的 设计 ， 介 绍 了 信息 
隐藏 类 的 设计 ， 被 动 对 象 将 通过 对 这 种 类 的 实例 化 来 创建 。 这 些 类 最 初 是 在 分 析 建 模 中 的 对 
象 和 类 组 织 步骤 中 确定 的 ， 如 第 8 章 所 述 。 本 章 还 介绍 了 每 个 类 中 操作 的 设计 、 类 接口 的 设 
计 以 及 如 何在 软件 设计 中 使 用 继承 。 关 于 类 和 继承 的 设计 以 及 在 软件 构造 中 如 何 使 用 前 置 条 
件 、 后 置 条 件 和 不 变量 的 更 多 信息 ， 一 个 非常 好 的 参考 是 文献 Meyer (2000). 5 — “#8 
参考 是 从 UML 的 角度 描述 这 些 主题 的 文献 Раре-Јопеѕ ( 2000 )。 

使 用 本 章 介 绍 的 面向 对 象 设计 思想 可 以 得 到 一 个 顺序 性 的 面向 对 象 软件 体系 结构 设计 ， 
这 种 设计 可 以 被 实现 为 一 个 仅 拥有 一 个 控制 线程 的 顺序 性 程序 。 一 个 顺序 性 面向 对 象 软件 体 
系 结构 的 设计 实例 是 第 21 章 中 所 介绍 的 “银行 系统 ”案例 研究 中 的 “银行 服务 ” 子 系统 。 

面向 对 象 概念 在 更 高 级 的 软件 体系 结构 的 设计 中 同样 可 以 得 到 应 用 和 扩展 ， 包 括 客户 端 / 
服务 器 软件 体系 结构 (第 15 章 )、 面 向 服务 的 体系 结构 (第 16 章 )、 基 于 构件 的 软件 体系 结构 
(第 17 章 )、 并 发 实时 软件 体系 结构 (第 18 章 ) 和 软件 产品 线 体系 结构 (第 19 章 )。 


练习 


选择 题 ( 每 道 题 选择 一 个 答案 ) 
1. 什么 是 信息 隐藏 对 象 ? 


(a) 封装 数据 的 主动 对 象 (b) 封装 数据 的 被 动 对 象 
(с) 封装 数据 的 类 (а) 封装 数据 的 任务 
2. 什么 是 类 接口 ? 
(a) 定义 了 类 操作 的 内 部 细节 (b) 定义 了 类 的 外 部 可 见 操作 
(с) 定义 了 类 操作 的 参数 (d) 定义 了 类 操作 的 型 构 
3. 下 面 哪 一 项 不 是 面向 对 象 概念 ? 
(а) 信息 隐藏 (b) 类 
(с) 子 类 (d) 子 程序 
4. 下 面 哪 一 种 类 是 实现 接口 的 类 ? 
(a) 调用 接口 的 类 (b ) 实现 接口 的 类 


(с) 被 接口 所 调用 的 类 (d) 独立 于 接口 的 类 
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5. 下 面 哪 一 种 类 是 实体 类 ? 


(a) 信息 隐藏 类 (b ) 子 类 

(с) 控制 类 (4) 数据 抽象 类 

6. 状态 机 类 封装 了 什么 ? 

(a) 状态 转换 表 (b ) 状态 图 

(с) 机 器 当前 状态 (4) 状态 转换 表 和 机 器 的 当前 状态 
7. 下列 哪 一 项 不 太 可 能 是 图 形 用 户 界面 类 ? 

(a) 菜单 (b) 窗口 

(с) 按钮 (4) 个 人 识别 码 

8. 下 列 哪 一 项 不 太 可 能 被 封装 在 业务 逻辑 类 中 ? 

(a) 业务 规则 


(b ) 对 实体 类 操作 的 调用 
(c) 如 果 账 户 余额 小 于 10 美元 则 拒绝 提取 现金 


(а) 对 话 框 
9. 下 列 哪 一 项 是 继承 所 不 允许 的 ? 

(a) 子 类 从 超 类 继承 属性 (b) 子 类 从 超 类 继承 操作 

(с) 子 类 重新 定义 从 超 类 继承 的 属性 (d ) 子 类 重新 定义 从 超 类 继承 的 操作 
10. 下 列 哪 种 关于 抽象 类 的 说 法 是 正确 的 ? 

(a) 抽象 类 用 来 作为 创建 对 象 的 模板 (b ) 抽象 类 用 来 作为 创建 子 类 的 模板 
(с) 抽象 类 用 来 作为 创建 类 的 模板 ( 4) 抽象 类 用 来 作为 创建 超 类 的 模板 
11. 在 面向 对 象 设计 中 多 态 意味 着 : 

(a) 不 同 的 类 可 以 有 相同 的 名 字 (b ) 不 同 的 类 可 以 有 相同 的 接口 名 251 
(c) 不 同 的 类 可 以 有 相同 的 超 类 名 (а) 不 同 的 类 可 以 有 相同 的 操作 名 
12. 有 了 多 态 和 动态 绑 定 ， 一 个 对 象 可 以 : 

(а) 调用 相同 对 象 的 不 同名 称 的 操作 (b ) 调用 不 同 对 象 的 不 同名 称 的 操作 


(с) 调用 相同 对 象 的 相同 名 称 的 操作 Cd) 调用 不 同 对 象 的 相同 名 称 的 操作 252 
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设计 客户 端 /服务 器 软件 体系 结构 





本 章 将 介绍 客户 端 /服务 器 系统 的 软件 体系 结构 设计 。 在 这 类 系统 中 ， 客 户 端 是 服务 的 
请 求 者 ， 而 服务 器 则 是 服务 的 提供 者 。 典 型 的 服务 器 包括 文件 服务 器 、 数 据 库 服务 器 以 及 行 
式 打印 机 服务 器 。 客 户 端 / 服务 器 体系 结构 是 基于 客户 端 /服务 体系 结构 模式 的 ， 该 模式 最 简 
单 的 形式 是 包含 一 个 服务 和 多 个 客户 端 。 这 种 模式 有 多 个 变 体 ， 这 些 都 将 在 本 章 中 进行 介绍 。 
此 外 ， 在 设计 客户 端 /服务 器 体系 结构 的 时 候 ， 还 需要 考虑 某 些 决策 ， 例 如 服务 器 应 该 被 设 
计 为 一 个 顺序 的 还 是 并 发 的 子 系统 、 设 计 客 户 端 /服务 器 体系 结构 时 要 使 用 什么 样 的 体系 结 
构 的 结构 模式 以 及 对 于 客户 端 和 服务 之 间 的 交互 使 用 什么 样 的 体系 结构 通信 模式 等 。 

本 章 对 服务 器 和 服务 进行 了 区 分 。 服 务 器 是 一 个 为 多 个 客户 端 提供 一 个 或 多 个 服务 的 硬 
VE /软件 系统 。 服 务 在 客户 端 /服务 器 系统 中 是 指 一 个 满足 多 个 客户 端 需要 的 应 用 软件 构件 。 
由 于 服务 是 在 服务 器 上 执行 的 ， 因 此 有 时 候 这 两 个 术语 会 被 混淆 ， 并 且 有 时 候 这 两 个 术语 是 
可 以 互 换 使 用 的 。 有 时 候 一 个 服务 器 会 支持 单一 的 服务 ， 但 有 时 候 也 可 能 支持 多 个 服务 ; 另 
一 方面 ， 一 个 大 的 服务 也 有 可 能 要 跨越 多 个 服务 器 结 点 。 在 客户 端 /服务 器 系统 中 ， 服 务 是 
在 固定 的 服务 器 结 点 上 执行 的 ， 并 且 客 户 端 到 服务 器 有 着 固定 的 连接 。 

15.1 节 介 绍 客户 端 /服务 器 体系 结构 的 概念 、 体 系 结构 以 及 模式 。15.2 WA 15.3 节 介 绍 
客户 端 /服务 软件 体系 结构 方面 的 模式 , 15.4 节 对 客户 端 /服务 器 系统 的 中 间 件 技术 进行 概述 。 
15.5 节 介 绍 顺 序 服 务 子 系统 和 并 发 服务 子 系统 的 设计 。 由 于 服务 器 经 常 是 数据 库 密集 型 的 ， 
因此 15.6 节 介 绍 包装 器 类 ， 这 将 会 引出 关于 数据 库 包 装 器 类 的 讨论 。 接 下 来 的 15.7 节 介 绍 客 
户 端 /服务 器 系统 的 逻辑 数据 库 设计 。 


15.1 客户 端 /服务 器 体系 结构 的 概念 、 体 系 结构 和 模式 


本 章 将 会 介绍 客户 端 /服务 器 软件 体系 结构 ， 其 中 包含 多 个 客户 端 和 一 个 或 者 多 个 服务 。 
此 外 ， 本 章 还 会 介绍 顺序 性 服务 和 并 发 服务 的 特性 。 第 16 章 将 介绍 面向 服务 的 软件 体系 结 
构 ， 这 种 体系 结构 建立 在 松 耦 合 服务 的 基础 上 ， 而 客户 端 可 以 通过 服务 代理 发 现 和 连接 服务 。 
第 17 章 介绍 了 一 个 更 通用 的 基于 构件 的 软件 体系 结构 ， 其 中 所 有 的 类 都 被 设计 为 构件 。 

最 简单 的 客户 端 /服务 器 体系 结构 包含 一 个 服务 以 及 多 个 客户 端 ， 更 复杂 的 客户 端 / 服 
务 器 系统 可 能 包含 多 个 服务 。15.2 节 介 绍 了 各 种 不 同 的 客户 端 /服务 器 体系 结构 的 结构 模式 ， 
包括 多 客户 端 / 单 服务 模式 和 多 客户 端 / 多 服务 模式 。15.3 节 介绍 了 客户 端 /服务 器 体系 结构 
的 通信 模式 ， 包 括 带 回复 的 同步 消息 通信 和 带 回调 的 异步 消息 通信 。 


15.2 客户 端 / 服 务 软件 体系 结构 的 结构 模式 


本 节 介 绍 各 种 不 同 的 客户 端 /服务 软件 体系 结构 的 结构 模式 ， 包 括 多 客户 端 单 服务 、 多 
客户 端 多 服务 和 多 层次 客户 端 / 服务 器 体系 结构 。 


15.2.1 多 客户 端 / 单 服务 体系 结构 模式 
多 客户 端 / 单 服务 体系 结构 模式 包含 多 个 请 求 同 一 个 服务 的 客户 端 以 及 一 个 满足 客户 端 
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请 求 的 服务 。 最 简单 、 最 常见 的 客户 端 /服务 器 体系 结构 有 一 个 服务 和 多 个 客户 端 ， 因 此 多 
客户 端 / 单 服务 体系 结构 模式 也 被 称 作 客户 端 / 服 务 器 或 者 客户 端 / 服 务 模 式 。 多 客户 端 / 单 
服务 体系 结构 的 模式 可 以 用 如 图 15-1 所 示 的 部 署 图 来 描述 ， 其 中 多 个 客户 端 通过 一 个 局 域 网 
连接 到 一 个 在 服务 器 结 点 上 运行 的 服务 。 


Service 
{1 server node} 
«local area network» 




















Я TE ЕЙ 
Client’ Client2 Client3 
图 15-1 多 客户 端 / 单 服务 体系 结构 模式 


该 模式 的 一 个 例子 是 “银行 系统 "， 如 图 15-2 的 类 图 所 示 。 这 个 系统 包含 多 个 АТМ 机 和 一 个 
银行 服务 ， 其 中 每 一 个 AMT 机 都 对 应 于 一 个 “ATM 客户 端子 系统 ”， 该 子 系统 通过 读 取 АТМ Е 
以 及 在 键盘 /显示 屏幕 上 提示 交易 的 详细 信息 来 处 理 银 行 客户 的 请 求 。 对 于 一 个 允许 执行 的 取款 
请 求 ，ATM 会 提供 现金 、 打 印 收据 ， 并 吐出 АТМ 卡 。“ 银 行 服务 ”维护 着 关于 银行 客户 账户 和 
ATM 卡 的 数据 库 ， 验 证 ATM 交易 事务 ， 并 根据 客户 账户 的 状态 决定 接受 或 者 拒绝 客户 的 请 求 。 


Е лө «external user» 
«external output device» Operator 
ReceiptPrinter 







«software system» 
BankingSystem 


1 1 
«client» 
«subsystem» 
р ATMClient 








Requests Service 
From 


«service» 
«subsystem» 
BankingService 


«external input/output 
device» 
CardReader 
«external output device» 
CashDispenser «external user» 
ATMCustomer 


图 15-2 多 客户 端 / 单 服 务 体系 结构 模式 示例 : 银行 系统 
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多 客户 端 / 单 服务 体系 结构 模式 可 以 用 如 图 15-3 所 示 的 通信 图 来 描述 。 图 15-3 中 描述 
的 是 “银行 系统 "， 该 系统 还 将 在 第 19 章 中 进行 更 详细 的 介绍 。 在 这 个 例子 中 ， 客 户 端 是 
“АТМ 客户 端 ” 构 件 ， 这 些 构件 向 “银行 服务 ”发 送 同步 消息 。 每 一 个 客户 端 都 与 服务 紧密 
耦合 在 一 起 ， 因 为 客户 端 发 送 一 条 消息 后 就 会 等 待 服务 的 回复 。 服 务 在 接收 了 消息 之 后 会 进 
行 处 理 ， 准 备 回复 消息 然后 将 应 答 发 送 回 客户 端 。 收 到 服务 的 应 答 之 后 ， 客 户 端 会 继续 执行 。 


1: sendATMTransaction ( іп transaction, out response) 
— А 
«client» «service» | 
: ATMClient : BankingService 


Р 15-3 多 客户 端 / 单 服 务 体系 结构 模式 示例 :“ 银 行 系统 ”通信 图 





15.2.2 ”多 客户 端 / 多 服务 体系 结构 模式 


更 加 复杂 的 客户 端 / 服务 器 系统 可 能 包含 多 个 服务 。 在 多 客户 端 / 多 服务 模式 中 ， 除 了 请 
求 服务 的 多 个 客户 端 外 ， 每 个 客户 端 也 可 能 会 与 多 个 服务 通信 ， 同 时 服务 之 间 可 能 也 会 互相 
进行 通信 。 多 客户 端 /多 服务 模式 可 以 用 如 图 15-4 所 示 的 部 署 图 描述 ， 其 中 每 个 服务 位 于 一 
个 独立 的 服务 器 结 点 上 ， 并 且 都 可 以 被 同一 个 客户 端 调用 。 在 这 个 模式 中 ， 一 个 客户 端 可 以 
以 顺序 性 的 方式 与 多 个 服务 通信 ， 也 可 以 同时 与 多 个 服务 并 发 地 通信 。 












Service1 
{1 server node} 





Service2 
{1 server node} 





«local area network» | 








А ЕЕ 2 РИ 
Client1 Client2 Client3 
{1 client node} {1 client node} {1 client node} 


图 15-4 多 客户 端 /多 服务 体系 结构 模式 


多 客户 端 / 多 服务 结构 体系 模式 的 一 个 例子 是 包含 多 家 互联 互通 的 银行 的 银行 业务 联盟 ， 
例如 图 15-5 中 所 示 的 银行 联盟 系统 。 继 续 考 虑 АТМ 的 例子 ， 除 了 多 个 ATM 客户 端 可 以 访问 
同一 个 银行 服务 之 外 ,一 个 АТМ 客户 端 也 可 以 访问 多 家 银行 的 服务 。 这 一 特性 使 得 客户 可 以 
通过 其 他 银行 的 ATM 客户 端 来 访问 自己 银行 卡 所 属 银行 的 服务 。 在 这 个 例子 中 ，Sunrise 银 
{т АТМ 机 的 用 户 除了 可 以 从 该 银行 的 账户 中 取款 外 ， 也 可 以 从 Sunset 银行 中 取款 ， 反 之 亦 
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SR, М 15-5 描述 了 两 个 银行 服务 ， 即 “Sunrise 银行 服务 ”和 “Sunset 银行 服务 ”， 同 时 也 描 
述 了 两 个 银行 的 客户 端 实例 ， 即 “Sunrise ATM 客户 端 ” 和 “Sunset ATM 客户 端 ”。 






Sunrise Bank 








Sunset Bank 
Service 
{1 server node} 





Service 
{1 server node} 









«Wide area network» | 






















"A SE < ff 
Sunrise Sunset Sunrise Sunset 
ATM Client1 ATM Client2 ATM Client3 ATM Client4 
{1 client node} {1 client node} {1 client node} {1 client node} 


15-5 多 客户 端 / 多 服务 体系 结构 模式 示例 : 银行 联盟 系统 


15.2.3 ”多 层 客 户 端 / 服 务 体系 结构 模式 


多 层 客 户 端 /服务 模式 有 一 个 同时 扮演 着 客户 端 和 服务 角色 的 中 间 层 。 一 个 中 间 层 对 于 
它 的 服务 层 而 言 是 一 个 客户 端 ， 而 对 于 其 客户 端 而 言 又 能 提供 服务 。 在 一 个 体系 结构 中 拥有 
多 个 中 间 层 也 是 有 可 能 的 。 当 被 视 为 一 个 层次 化 的 体系 结构 时 ， 客 户 端 相对 于 服务 而 言 处 于 
一 个 较 高 的 层 上 ， 因 为 客户 端 依赖 于 服务 并 且 要 使 用 那些 服务 。 


ATMClient BankingService DatabaseService 





Al 15-6 多 层 客户 端 /服务 体系 结构 模式 示例 : 一 个 三 层 的 银行 系统 


图 15-6 中 描述 了 一 个 “银行 系统 ”的 三 层 客户 端 /服务 模式 的 例子 。 在 这 个 例子 中 ， 
“银行 服务 ” 层 向 “ATM 客户 端 ” 层 提供 服务 ， 同 时 它 自己 又 是 “数据 库 服 务 ”( Database 
Service) 层 的 一 个 客户 端 。 由 于 第 三 层 是 由 一 个 COTS ( 商用 现货 ) 数据 库 管 理 系统 提供 的 ， 
并 不 是 应 用 软件 的 一 部 分 ， 因 此 没有 在 图 15-3 的 应 用 级 别 通信 图 中 进行 详细 的 描述 。 此 外 ， 
“银行 服务 ”和 “数据 库 服 务 ” 可 以 在 同一 个 服务 需 结 点 上 运行 。 


15.3 客户 端 /服务 器 体系 结构 的 通信 模式 
在 客户 端 /服务 器 的 通信 中 ， 客 户 端 通常 向 服务 发 送 请 求 并 且 从 服务 那里 接收 一 个 回复 。 
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有 些 时 候 服务 请 求 可 能 没有 回复 ， 例 如 当 更 新 数据 而 非 请 求 数 据 时 。 客 户 端 和 服务 之 间 的 通 
信 状 况 影 响 着 通信 模式 的 选择 。 有 多 种 软件 体系 结构 的 通信 模式 可 供 使 用 ， 具 体 如 下 。 

ө 带 回复 的 同步 消息 通信 ， 在 15.3.1 节 中 进行 介绍 。 

ө 异步 消息 通信 ， 在 第 12 章 中 进行 了 介绍 。 

e 带 回调 的 异步 消息 通信 ， 在 15.3.2 节 中 进行 介绍 。 

о 不 带 回复 的 同步 通信 ， 在 第 18 章 中 进行 介绍 。 

° 代理 者 模式 ， 在 第 16 章 中 进行 介绍 。 

ө 群 组 通信 和 模式， 在 第 17 章 中 进行 介绍 。 


15.31 ” 带 回 复 的 同步 消息 通信 模式 


对 于 客户 端 /服务 器 通信 而 言 ， 最 常见 的 软件 体系 结构 通信 模式 是 带 回 复 的 同步 消息 通 
言 ， 也 称 作 请 求 / 响应 模式 。 

带 回复 的 同步 消息 通信 ( 见 图 15-7 ) 可 以 包含 一 个 向 服务 发 送 消 息 并 等 待 回复 的 客户 
端 ， 在 这 种 情况 下 客户 端 和 服务 之 间 不 需要 消息 队列 。 然 而 ， 这 种 模式 通常 会 包含 多 个 与 
单个 服务 进行 交互 的 客户 端 ， 如 下 文 所 述 。 在 典型 的 客户 端 / 服 务 器 情形 下 ， 每 一 个 客户 
端 向 一 个 服务 发 送 一 条 请 求 消息 并 等 待 服务 的 答复 。 在 这 个 模式 中 ， 由 于 多 个 客户 端 向 服 
务 发 送 请 求 ， 因 此 会 在 服务 端 建立 一 个 消息 队列 。 客 户 端 使 用 同步 消息 通信 并 且 等 待 服务 


的 答复 。 
=] 1: sendSynchronousMessageWithReply (in request, 
out response) 
客户 端 与 服务 之 间 是 使 用 同步 还 是 异步 消息 通信 取决 于 相应 的 应 用 ， 并 且 不 会 对 于 服务 


Р 15-7 带 回复 的 同步 消息 通信 

的 设计 产生 影响 。 实 际 上 ， 对 于 同一 个 服务 ， 有 些 客户 端 可 以 与 其 进行 同步 通信 ， 而 其 他 客 
户 端 可 以 与 其 进行 异步 通信 。 一 个 使 用 带 回 复 的 同步 消息 通信 的 多 客户 端 / 单 服务 消息 通信 
的 例子 如 图 15-8 所 示 。 在 这 个 例子 中 ,“ 银 行 服务 ”响应 来 自 多 个 客户 端的 服务 请 求 ， 这 些 
客户 端 包括 用 户 客 户 端 和 ATM 客户 端 。 "银行 服务 ”有 一 个 消息 队列 ， 用 来 存放 来 自 多 个 客 
户 端的 同步 请 求 。 每 一 个 “ATM 客户 端 ” 构 件 向 “银行 服务 ”发 送 一 个 同步 消息 并 且 等 待 回 
Я. ARAVA FIFO ( 先 来 先 服务 ) 的 原则 处 理 每 一 条 收 到 的 交易 消息 ， 并 且 向 客户 端 发 送 一 个 
同步 的 回复 消息 。 

如 果 客 户 端 和 服务 器 之 间 存 在 包含 多 条 消息 和 回复 的 会 话 ， 那 么 它们 之 间 会 建立 一 个 连 
接 。 消 息 会 通过 该 连接 来 进行 发 送 和 接收 。 


15.3.2” 带 回调 的 异步 消息 通信 模式 


当 客户 端 和 服务 之 间 的 通信 方式 符合 以 下 情形 时 可 以 使 用 带 回 调 的 异步 消息 通信 模式 : 
客户 端 向 服务 发 送 了 一 条 请 求 后 可 以 继续 执行 自己 的 工作 而 不 需要 等 待 服务 的 应 答 ， 但 服务 
需要 在 稍 后 向 客户 端 发 送 答复 信息 ( 见 图 15-9 )。 回 调 是 对 于 一 个 客户 端 早 些 时 候 发 送 的 请 求 
消息 的 一 个 异步 应 答 。 这 个 模式 允许 客户 端 异 步 执 行 ， 但 仍然 遵循 客户 端 / 服务 的 规范 ， 即 
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个 客户 端 在 同一 时 间 只 会 向 服务 发 送 一 条 请 求 消息 并 且 收 到 服务 的 应 答 。 


П 
«user interaction» «service» | 
: UserClient : BankingService 
[ 
«client» 
: ATMClient 


РӘ 15-8 带 回复 的 同步 消息 通信 模式 示例 : 银行 应 用 


使 用 回调 模式 时 ， 客 户 端 发 送 一 个 远程 引用 或 者 句柄 ， 之 后 服务 将 使 用 这 些 引用 或 句柄 
向 客户 端 发 送 回复 。 一 个 回调 模式 的 变种 是 服务 将 回调 处 理 转发 给 另外 一 个 构件 ， 从 而 将 答 
复 委 派 给 这 个 构件 。 








1: sendBankingTransaction (in transaction, out response) 
— 
















2: sendATMTransaction 
(in transaction, out response) 


ao 










1: sendAsynchronousMessage 
(in message, in callbackHandle) 


—> 
<< 
2: sendCallbackResponse ( in response) 


Е 15-9 带 回 调 的 异步 消息 通信 和 模式 










15.4 客户 端 /服务 器 系统 的 中 间 件 


中 间 件 在 软件 中 是 处 于 各 种 操作 系统 之 上 的 一 层 ， 其 目的 是 提供 一 个 统一 的 平台 使 得 各 
种 分 布 式 的 应 用 都 能 在 其 上 运行 ， 如 客户 端 /服务 器 系统 (Bacon 1997 )。 中 间 件 的 早期 形式 
是 远程 过 程 调 用 (RPC )， 其 他 的 一 些 中 间 件 技术 的 例子 ( Szyperski 2003 ) 包括 : 使 用 RPC 
技术 的 分 布 式 计算 环境 (DCE), Java 远程 方法 调用 (RMI )、 构 件 对 象 模型 (COM), Jini 的 
Јама 2 平台 企业 版 (J2EE ) 以 及 通用 对 象 请 求 代 理 体系 结构 (CORBA )。 

在 客户 端 /服务 器 配置 中 的 一 个 中 间 件 例子 如 图 15-10 所 示 ， 在 客户 端 结 点 上 的 是 使 用 
图 形 用 户 界 面 (GU) 的 客户 端 应 用 。 此 外 ， 客 户 端 结 点 上 还 有 一 个 标准 的 操作 系统 ( 如 
Windows ) 以 及 一 个 网 络 通信 软件 (例如 在 Internet 上 使 用 最 广泛 的 TCP/IP )。 中 间 件 层 位 于 
操作 系统 和 网 络 通信 软件 之 上 。 在 服务 器 结 点 上 的 是 使 用 中 间 件 服务 的 服务 应 用 软件 ， 其 中 
中 间 件 位 于 操作 系统 ( 如 UNIX, Linux 或 者 Windows ) 和 网 络 通信 软件 之 上 。 文 件 管理 系统 
或 者 数据 库 管 理 系统 ( 通常 是 关系 数据 库 ) 被 用 于 持久 化 的 信息 存储 。 


15.4.1 客户 端 / 服 务 器 系统 平台 


客户 端 /服务 器 体系 结构 中 的 通信 经 常 是 同步 通信 ， 通 常 是 由 中 间 件 技术 ( 如 远程 过 程 
调用 (RPC ) 或 者 远程 方法 调用 (RMI ) ) 来 提供 的 。 通 过 远程 过 程 调用 ， 位 于 服务 器 的 地 址 
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空间 之 中 的 过 程 可 以 被 远程 过 程 调 用 。 服 务 器 接收 客户 端 请 求 ， 调 用 合适 的 过 程 ， 并 把 结果 
返回 给 客户 端 。 


Client 
node 


Client Application Software / GUI 
software 
Middleware 
Operating System 
Communication Software 















Р 15-10 客户 端 和 服务 器 结 点 上 的 中 间 件 示例 


15.4.2 Java 远程 方法 调用 


Java 编程 环境 支持 名 为 Јама 远程 方法 调用 (RMI ) 的 中 间 件 技术 ， 该 技术 允许 分 布 式 的 
Java 对 象 之 间 进 行 通信 。 使 用 RMI 的 客户 端 对 象 向 一 个 特定 的 服务 对 象 发 送 消 息 ， 并 且 调 用 
该 对 象 的 方法 〈 过 程 或 者 函数 )， 而 不 是 像 RPC 那样 向 一 个 特定 的 过 程 发 送 消息 。 

客户 端 结 点 上 的 客户 端 对 象 对 服务 器 结 点 上 的 服务 对 象 进 行 远程 方法 调用 。 远 程 方法 调 
用 和 本 地 方法 调用 相似 ， 因 此 服务 对 象 是 在 远程 服务 器 结 点 上 的 这 一 差异 对 于 客户 端 来 说 是 
隐藏 的 。 

客户 端 代理 为 客户 端 对 象 提供 与 服务 对 象 相同 的 接口 ， 并 且 隐 藏 所 有 来 自 客户 端的 通信 
细节 。 在 服务 器 方面 ， 服 务 代理 隐藏 了 所 有 来 自 服务 对 象 的 通信 和 细节。 服务 代理 调用 服务 对 
象 的 方法 。 如 果 服 务 对 象 不 存在 ， 那 么 服务 代理 会 实例 化 服务 对 象 。 

客户 端的 本 地 方法 调用 是 由 客户 端 代理 提供 的 。 客 户 端 代 理 将 本 地 请 求 和 参数 
封装 进 通信 的 消息 里 一 一 这 一 过 程 通常 被 称 作 编组 (marshalling )， 然 后 将 消息 发 送 
给 服务 器 结 点 。 在 服务 器 结 点 上 ， 服 务 代 理 将 消息 解 包 一 一 这 一 过 程 通常 被 称 作 解 组 
( unmarshalling )， 然 后 调用 合适 的 服务 方法 (这 就 代表 着 远程 方法 调用 ) 并 将 参数 传递 过 
去 。 服 务 方法 完成 请 求 的 处 理 后 会 将 结果 返回 给 服务 代理 。 服 务 代理 将 结果 封装 进 回 复 消 
息 中 ,并且 将 消息 发 送 给 客户 端 代理 。 客 户 端 代理 从 消息 中 提取 出 结果 ， 并 将 其 作为 输出 
参数 返回 给 客户 端 对 象 。 

因此 ， 客 户 端 代理 和 服务 代理 所 扮演 的 角色 是 使 得 远程 方法 调用 对 于 客户 端 和 服务 而 言 
就 如 同 本 地 方法 调用 一 样 ， 如 图 15-11 所 示 。 图 15-11a 描述 了 一 个 对 象 向 另 一 个 对 象 所 进行 
的 本 地 方法 调用 。 图 15-111 中 的 通信 图 描述 了 对 于 同一 个 问题 的 分 布 式 解决 方案 中 的 消息 序 
列 ， 其 中 一 个 客户 端 结 点 上 的 对 象 调 用 了 服务 器 结 点 上 的 服务 对 象 的 远程 方法 。 本 地 方法 调 
用 是 对 于 客户 端 代理 的 调用 (1 )， 客 户 端 代理 将 方法 名 和 参数 编组 进 消息 里 ， 然 后 将 消息 通 
过 网 络 发 送 ( 2 )。 远 程 结 点 上 的 服务 代理 接收 消息 ， 解 组 消息 ， 并 调用 服务 对 象 的 远程 方法 
(3 )。 对 于 服务 响应 ( 4 )， 服 务 代理 对 响应 消息 进行 编组 并 通过 网 络 发 送 (5 )。 客 户 端 代理 将 
响应 消息 解 组 并 将 其 发 送 回 客 户 端 对 象 (6 )。 
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1: serviceRequest 
(in inputParam) 








{ ^ 2: serviceResponse 





Server node 






3: serviceRequest 4 ду 4: serviceResponse 
(in inputParam) 





b) 
图 15-11 远程 方法 调用 (RMI) 


15.5 ”服务 子 系统 的 设计 


一 个 服务 子 系统 为 多 个 客户 端 提供 服务 。 如 15.2.3 节 中 所 指出 的 ， 服 务 经 常 需要 访问 存 
储 持久 性 数据 的 数据 库 。15.7 节 介 绍 了 关系 数据 库 的 设计 ，15.6 节 介 绍 了 提供 面向 对 象 的 数 
据 库 访 问 接口 的 包装 器 类 的 设计 。 

一 个 简单 的 服务 并 不 会 发 起 任何 服务 请 求 ， 而 只 是 对 来 自 客户 端的 请 求 进行 响应 。 有 两 
种 服务 构件 : 顺序 性 的 和 并 发 的 。 


15.5.1 ”顺序 性 服务 的 设计 


一 个 顺序 性 服务 顺序 地 处 理 客户 端的 请 求 ， 这 就 意味 着 这 种 服务 必须 先 完成 上 一 个 服务 
请 求 才能 开始 处 理 下 一 个 请 求 。 一 个 顺序 性 服务 被 设计 为 一 个 并 发 对 象 ( 控制 线程 ) 来 响应 来 
自 客户 端的 服务 访问 请 求 。 例 如 ， 一 个 简单 的 顺序 性 服务 接收 来 自 客户 端的 请 求 ， 这 些 请 求 要 
去 更 新 或 者 读 取 一 个 被 动 数据 抽象 对 象 的 数据 。 服 务 接收 到 来 自 客户 端的 消息 后 会 调用 由 被 动 
数据 抽象 对 象 提供 的 相应 的 操作 ， 例 如 在 一 个 银行 业务 应 用 中 从 一 个 账户 对 象 存款 或 取款 。 

服务 通常 都 会 有 一 个 消息 队列 来 存放 收 到 的 服务 请 求 。 每 一 个 由 服务 提供 的 操作 都 对 应 
一 种 消息 类 型 。 服 务 协调 者 将 来 自 客 户 端的 消息 解 包 ， 然 后 根据 消息 的 类 型 调用 相应 的 服务 
对 象 所 提供 的 操作 。 消 息 的 参数 将 作为 操作 的 参数 。 服 务 对 象 处 理 客户 端的 请 求 并 将 相应 的 
响应 返回 给 服务 协调 者 ， 之 后 协调 者 会 准备 一 个 服务 响应 消息 并 将 其 发 送 给 客户 端 。 


15.5.2 ”顺序 性 服务 设计 示例 
这 里 给 出 的 顺序 性 服务 的 例子 是 “银行 系统 ”中 的 “银行 服务 ”"。 由 基于 用 例 的 通信 图 的 
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集成 构成 的 “银行 服务 ”集成 通信 图 ( 参见 第 13 章 ) 描述 了 服务 中 所 包含 的 所 有 对 象 以 及 它 
们 之 间 的 交互 。 由 于 对 象 之 间 的 所 有 通信 都 是 通过 操作 调用 的 方法 ， 对 象 接口 被 设计 为 显示 
同步 操作 调用 以 及 每 一 个 操作 的 输入 和 输出 参数 〈 使 用 在 第 14 章 介绍 的 指南 )， 如 图 15-12 
所 示 。 

在 图 15-12 中 ,“ 银 行 服务 ”顺序 地 服务 来 自 客户 端的 АТМ 交易 ， 包 括 PIN 码 验证 请 求 、 
账户 取款 请 求 、 账 户 间 转账 请 求 以 及 账户 查询 请 求 。“ 银 行 服务 ”处 理 这 些 交 易 ， 调 用 服务 操 
作 ， 向 客户 端 返回 “银行 响应 ”( bankResponse ) 消息 ， 然 后 再 接着 处 理 下 一 个 交易 。 每 一 个 
交易 都 会 在 下 一 个 交易 开始 前 执行 完成 。 顺 序 性 服务 设计 应 该 只 在 服务 器 结 点 有 足够 的 能 力 
充分 应 对 交易 请 求 频率 的 情况 下 被 使 用 。 

服务 设计 使 用 了 抽象 模式 层次 。 由 于 服务 数据 是 存储 在 关系 数据 库 中 的 ， 因 此 体系 结构 
中 最 底层 的 是 数据 库 包装 器 对 象 ( 见 15.6 节 )， 其 中 封装 了 对 于 数据 库 中 数据 的 访问 方式 。 
在 此 之 上 的 一 层 是 业务 逻辑 对 象 ， 封 装 了 处 理 客 户 端 请 求 的 业务 规则 。 处 于 最 高 层 的 是 协调 
者 对 象 ， 这 些 对 象 使 用 门面 模式 来 为 客户 端 提 供 统 一 的 接口 。 门 面 是 由 为 客户 端 提供 通用 接 
口 的 协调 者 对 象 提供 的 。 在 执行 过 程 中 ， 协 调 者 〈 提供 门面 的 对 象 ) 将 每 个 收 到 的 客户 端 请 
求 委托 给 合适 的 业务 逻辑 对 象 ， 接 下 来 这 些 逻 辑 处 理 对 象 又 与 访问 数据 库 (其 中 保存 了 账户 
和 借 记 卡 的 数据 ) 的 数据 库 封装 器 对 象 进行 交互 。 

因此 ， 当 一 个 ATM 客户 端 向 “银行 服务 ”发 送 一 个 PIN 码 验 证 请 求 时 ,“ 银 行 交 易 协 
调 者 ”( Bank Transaction Coordinator ) 收 到 这 个 请 求 后 将 其 委托 给 “PIN 码 验 证 交易 管理 器 ” 
(РМ Validation Transaction Manager )。 这 个 业务 逻辑 对 象 会 访问 “ 借 记 卡 ”( Debit Сага) 和 
“ 卡 账户 ”( Card Account ) 数据 库 包 装 器 对 象 来 执行 验证 ， 然 后 将 验证 结果 返回 给 协调 者 并 由 
其 向 客户 端 发 送 一 个 同步 的 响应 。 这 个 例子 将 会 在 第 21 章 中 所 介绍 的 客户 端 /服务 器 银行 系 
统 设 计 中 进行 更 为 详细 的 描述 。 

15.5.3 并 发 服务 设计 


在 并 发 服务 设计 中 ， 服 务 功能 由 多 个 并 发 的 对 象 共 同 完成 。 如 果 客 户 端 对 于 服务 的 要 求 
很 高 ， 以 至 于 顺序 性 服务 可 能 会 成 为 系统 中 潜在 的 瓶颈 ， 那 么 应 当 考 虑 让 一 个 由 多 个 并 发 对 
象 组 成 的 并 发 服务 来 提供 服务 。 这 种 方法 假设 通过 使 用 提供 并 发 数据 访问 的 对 象 可 以 提高 系 
统 的 吞吐 量 ， 例 如 当 数 据 存储 在 辅助 存储 中 时 。 

并 发 服务 设计 的 一 个 例子 如 图 15-13 所 示 。 这 个 例子 展示 了 “银行 服务 ”的 另 一 种 设计 方 
案 ， 其 中 “银行 交易 协调 者 ”和 每 一 个 交易 管理 器 被 设计 为 独立 的 并 发 对 象 。“ 银 行 交易 协调 
者 ”将 各 个 交易 的 处 理 委托 给 各 个 交易 管理 器 ， 从 而 允许 交易 的 并 发 处 理 。 每 个 交易 管理 器 还 
可 以 有 多 个 实例 一 起 执行 。 对 于 数据 库 包装 器 对 象 ( 未 在 图 中 显示 ) 的 访问 同样 需要 同步 。 

在 这 个 例子 中 ,客户 端 和 服务 之 间 的 通信 使 用 的 是 带 回 调 的 异步 消息 通信 模式 ( 见 
15.2.1 节 )。 这 意味 着 客户 端 在 收 到 服务 的 响应 之 前 不 需要 等 待 并 且 可 以 做 其 他 事情 。 在 这 种 
情况 下 ， 服 务 响应 被 处 理 为 回调 。 使 用 回调 的 方法 时 ， 客 户 端 在 初始 的 请 求 中 发 送 一 个 操作 
句柄 。 服 务 完 成 客户 端的 请 求 后 使 用 该 句柄 来 远程 调用 客户 端 操作 ( 回调 )。 在 图 15-13 所 示 
的 例子 中 ,“ 银 行 交 易 协 调 者 ”将 ATM 客户 端的 回调 句柄 传递 给 相应 的 交易 管理 器 。 当 服务 
完成 时 ， 交 易 管理 器 并 发 对 象 远程 调用 回调 ， 这 个 回调 被 描述 为 相应 的 发 送 给 АТМ 客户 端的 
服务 响应 消息 。 
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15.6 包装 器 类 的 设计 


虽然 许多 遗留 的 应 用 无 法 被 轻易 地 整合 到 一 个 新 的 应 用 中 ,但 是 有 一 个 可 能 的 方法 
是 开发 包装 器 类 。 包 装 器 类 是 一 种 处 理 客户 端 对 于 遗留 应 用 请 求 的 通信 和 管理 的 服务 器 类 
( Tanenbaum and Van Steen 2006 )。 

大 多 数 的 遗留 应 用 最 初 是 作为 一 个 独立 的 应 用 开发 的 。 有 时 候 可 以 通过 修改 遗留 代码 的 
方式 使 得 包装 器 类 可 以 访问 遗留 应 用 。 然 而 ， 这 种 方式 往往 是 不 切实 际 的 ， 因 为 遗留 代码 的 
文档 经 常会 缺失 很 多 甚至 完全 丢失 ， 而 最 初 的 开发 人 员 也 无 法 找到 。 因 此 ， 包 装 器 类 通常 需 
要 通过 一 种 粗糙 的 机 制 实现 与 遗留 代码 的 接口 ， 例 如 完全 通过 顺序 文件 或 索引 顺序 文件 。 包 
装 器 类 会 读 取 或 者 更 新 由 遗留 应 用 所 维护 的 文件 。 如 果 遗 留 应 用 使 用 一 个 数据 库 ， 那 么 该 数 
据 库 可 以 通过 数据 库 包 装 器 类 来 直接 访问 ， 同 时 隐藏 访问 的 细节 。 例 如 ， 对 于 一 个 关系 数据 
库 ， 数 据 库 包装 器 类 可 以 使 用 结构 化 查询 语言 ( SQL ) 来 访问 数据 库 。 

开发 者 可 以 通过 在 遗留 代码 周围 进行 包装 并 提供 访问 接口 的 方式 将 遗留 代码 整合 进 一 个 
客户 端 /服务 器 应 用 。 包 装 器 会 将 来 自 客 户 端的 外 部 请 求 转化 为 对 于 遗留 代码 的 调用 。 包 装 
器 也 会 将 遗留 代码 的 输出 转化 成 对 于 客户 端的 响应 。 


15.6.1 ”数据库 包装 器 类 的 设计 


分 析 模 型 中 的 实体 类 封装 了 一 些 数据 。 在 设计 过 程 中 需要 进一步 确定 被 封装 的 数据 是 否 
由 实体 类 直接 管理 ， 或 者 数据 实际 上 是 存储 在 数据 库 中 的 。 前 一 种 情况 由 数据 抽象 类 处 理 ， 
其 中 封装 了 数据 结构 ， 如 14.4 节 所 述 。 后 一 种 情况 由 数据 库 包 装 器 类 处 理 ， 其 中 隐藏 了 数据 
是 如 何 被 访问 的 〈 如 果 数 据 是 存储 在 数据 库 中 的 )， 这 种 方式 会 在 本 节 进 行 介 绍 。 在 客户 端 / 
服务 器 系统 的 设计 中 ， 数 据 抽象 类 更 有 可 能 位 于 客户 端 上 ， 但 也 可 能 位 于 服务 器 上 。 然 而 数 
据 库 包 装 器 类 在 大 多 数 时 候 则 是 位 于 服务 器 端 ， 因 为 数据 库 支持 是 在 服务 器 端 提供 的 。 

当前 使 用 的 数据 库 大 部 分 是 关系 数据 库 ， 所 以 数据 库 包装 器 类 可 以 提供 面向 对 象 的 数据 
库 访 问 接口 。 如 果 使 用 的 是 关系 数据 库 ， 那 么 需要 进一步 确定 静态 模型 中 所 定义 的 哪些 实体 
类 需要 映射 到 关系 数据 库 中 并 将 它们 设计 为 数据 库 包装 器 类 。 有 些 时 候 ， 通 过 数据 库 包装 器 
类 从 数据 库 中 检索 到 的 数据 会 被 临时 保存 在 数据 抽象 类 中 。 

分 析 模 型 实体 类 的 属性 会 被 映射 到 数据 库 关 系 表 上 ( 将 在 15.7 节 中 介绍 )。 访问 这 些 属 
性 的 操作 会 被 映射 到 数据 库 包 装 器 类 上 。 

数据 库 包 装 器 类 隐藏 了 如 何 访问 保存 在 关系 表 中 的 数据 的 细节 ， 所 以 隐藏 了 所 有 的 SQL 
语句 。 数 据 库 包装 器 类 通常 隐藏 对 于 关系 表 的 访问 细节 。 然 而 ， 数 据 库 包装 器 类 也 可 能 隐藏 
数据 库 视 图 ， 即 两 个 或 者 多 个 关系 的 SQL 表 连 接 (Silberschatz, Korth, and Sudarshan 2010 ). 


156.2 ”数据 库 包装 器 类 示例 


图 15-14 给 出 了 数据 库 包 装 器 类 的 一 个 例子 。 在 “银行 系统 ”的 例子 中 ， 所 有 的 持久 化 
数据 都 保存 在 数据 库 中 。 因 此 ， 银 行 服 务 器 的 每 个 实体 类 都 会 映射 为 一 张 数据 库 关 系 表 和 一 
个 数据 库 包装 器 类 。 例 如 ， 考 虑 图 15-14a 中 分 析 模 型 中 的 “ 借 记 卡 ”( Debit Сага) 实体 类 。 
由 于 借 记 卡 数据 保存 在 关系 数据 库 中 ， 因 此 从 数据 库 的 角度 来 说 该 实体 类 被 映射 为 一 张 数据 
库 关系 表 。 实 体 类 的 属性 被 映射 为 关系 属性 。 

此 外 还 需要 设计 针对 “ 借 记 卡 ” 的 数据 库 包装 器 类 ( 图 15-14b )， 并 提供 以 下 操作 : 
“创建 ”(create )、“ 验 证 ”( validate ) “检查 每 日 取款 上 限 ”(checkDailyLimit ), “清空 总 额 ” 
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(clearTotal ) “ВНР” (update), “EHR” (read) 以 及 “删除 ”( delete )。 这 些 操作 封装 了 访问 “ 借 
记 卡 ”关系 表 的 SQL 语句 。 注 意 ， 由 于 类 属性 可 以 被 分 别 更 新 ， 因 此 各 属性 都 有 其 自己 独立 的 
“更 新 ”操作 ， 例 如 每 日 取款 上 限 和 卡 状态 。 调 用 某 个 更 新 操作 便 会 执行 相应 的 SQL 语句 。 





«database wrapper» 


DebitCard 


+ create (cardID) 

+ validate (in cardID, in PIN, out status) 
+ updatePIN (cardID, PIN) 

+ checkDailyLimit (cardID, amount) 

+ updateDailyTotal (сага! ,, amount) 


«entity» 
DebitCard 


сага!) : String 

PIN : String 
startDate : Date 
expirationDate : Date 
status : Integer 

limit : Real 

total : Real 


а) 分 析 模 型 


+ updateCardStatus (саг О, status) 
+ updateDailyLimit (сага! О, newLimit) 
+ clearTotal (cardID) 
+ delete (сага! 0) 
b) 设计 模型 


图 15-14 数据库 包 装 器 类 示例 


157 ”从 静态 模型 到 关系 数据 库 的 设计 


+ UpdateExpirationDate (cardID, expirationDate) 





+ read (in cardID, out PIN, out expirationDate, out status, out limit, out total) 


本 节 介 绍 如 何 将 一 个 静态 模型 的 实体 类 中 所 包含 的 数据 映射 到 一 个 数据 库 中 。 当 前 所 使 
用 的 大 多 数 数据 库 都 是 关系 数据 库 ， 因 此 我 们 的 设计 目标 就 是 基于 概念 静态 模型 来 设计 关系 数 
据 库 ， 具 体 而 言 是 针对 那些 需要 持久 化 的 实体 类 。 关 于 关系 数据 库 设计 的 其 他 知识 ， 例 如 数据 
库 范 式 ， 请 参阅 一 些 标准 的 数据 库 教科 书 ， 例 如 Silberschatz，Korth，and Sudarshan ( 2010 )。 

参考 第 7 章 中 的 实体 类 建 模 对 理解 本 节 很 有 帮助 ， 那 是 关系 数据 库 设 计 的 起 点 。 关 系数 
据 库 的 设计 包括 关系 表 与 主键 的 设计 、 表 示 关 联 关系 的 外 键 设计 、 表 示 关 联 类 的 关联 表 设 计 、 


整体 /部 分 关系 (聚合 ) 设计 以 及 泛 化 / 特 化 关系 设计 等 。 


15.7.1 关系 数据 库 概 念 


关系 数据 库 由 一 系列 名 称 唯一 的 关系 表 组 成 。 在 
最 简单 的 情况 下 ， 每 个 实体 类 都 会 被 设计 为 一 张 关系 
数据 库 表 ， 表 名 与 实体 类 的 类 名 相对 应 。 实 体 类 的 每 
个 属性 对 应 到 相应 表 中 的 某 一 列 ， 每 个 对 象 对 应 为 表 
中 的 某 一 行 。 

例如 ， 实 体 类 “账户 ”( Account ) 被 设计 为 同名 的 关 
系 表 (参见 图 15-15 )。 其 属性 “账户 号 ”( accountNumber ) 
和 “余额 ”( balance ) 对 应 为 关系 表 中 的 两 列 。 每 个 账户 
的 一 个 实例 对 应 于 表 中 的 一 行 ， 如 表 15-1 所 示 ， 它 表示 
了 一 张 账户 表 以 及 三 个 独立 账户 。 

表 15-1 账户 关系 表 

accountNumber 

1234 

5678 

1287 


customerName: String 
customerld: String 
customerAddress: String 









accountNumber: Integer 
balance: Real 


1. 


Я 15-15 ”确定 主键 和 辅 键 (一 对 多 关联 ) 


balance 
398.07 
439.72 
851.65 
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15.7.2 BEER 


关系 数据 库 中 的 每 张 关系 表 都 必须 有 一 个 主键 。 在 最 简单 的 情况 下 ， 主 键 是 一 个 能 够 唯 
一 确定 表 中 某 一 行 的 属性 。 例 如 ， 账 户 号 是 账户 表 的 主键 ， 因 为 这 个 属性 能 够 唯一 确定 一 个 
账户 。 关 系 表 可 以 用 如 下 方式 来 表示 : 

Account( accountNumber，balance ) 

在 这 种 表示 法 中 ，Account 是 表 的 名 字 ，accountNumber 和 balance 是 表 的 属性 。 主 键 用 
下 划 线 表示 。 在 账户 表 中 accountNumber 就 表示 主键 。 

有 些 关系 表 中 需要 用 多 个 属性 来 表示 主键 。 例 如 ， 如 果 “ 账 户 ” 表 既 包 含 支票 账户 又 包 
含 储蓄 账户 〈 账 户 号 可 能 重复 )， 那 么 就 需要 另 一 个 属性 〈 账 户 类 型 ) 来 作为 主键 的 一 部 分 ， 
由 此 唯一 确定 一 个 账户 。 在 这 个 例子 中 ， 主 键 就 是 由 属性 accountNumber 和 accountType 共同 
组 成 的 一 个 复合 键 。 

Account (accountNumber, accountType, balance ) 


15.7.3 ”将 关联 映射 到 外 键 


关系 数据 库 中 的 关联 有 多 种 不 同 的 表示 方法 。 最 简单 的 方法 是 使 用 外 键 来 表示 一 对 一 关 
联 和 一 对 多 关联 ， 其 中 关联 关系 用 外 键 表示 。 外 键 是 包含 在 一 张 表 中 的 另 一 张 表 的 主键 ， 用 
以 表示 类 之 间 的 关联 关系 到 表 的 映射 。 外 键 可 以 让 我 们 从 一 张 表 导 航 到 另 一 张 表 。 

例如 ， 为 了 描述 “客户 ”和 “账户 ”之 间 的 关系 〈 如 图 15-15 中 的 类 图 所 示 )， 即 “ 客 
户 ” 拥 有 “账户 ”， 可 以 将 “客户 ” 表 的 主键 “客户 号 ”( customerId ) 作为 外 键 添加 到 “ 账 
户 ” 表 中 ， 而 “账户 ” 表 用 带 下 划 线 的 主键 和 和 斜体 的 外 键 表示 如 下 : 

Account ( accountNumber, balance, customerld ) 

用 这 种 方法 ， 我 们 可 以 从 “账户 ” 表 中 的 某 一 行 (例如 customerld 外 键 为 26537 的 那 一 
17) 导航 到 “客户 ” 表 中 具有 相同 customerld 主键 的 那 一 行 ， 由 此 可 以 获得 关于 某 个 客户 的 
更 多 消息 ， 如 表 15-2 所 示 。 


表 15-2 关系 表 之 间 的 导航 
从 账户 表 的 customerld ( 外 键 ) 导航 … 到 客户 表 中 的 customerld ( 主键 ) 
т 
398.07 24193 Smith 21849 
439.72 26537 Patel 26537 
851.65 21849 Chang 24193 


















accountNumber 
1234 
5678 
1287 


customerAddress 
New York 
Chicago 











Washington 





1. 将 一 对 一 关联 和 零 或 一 关联 映射 到 外 键 

在 表示 类 间 一 对 一 关联 时 ， 我们 可 以 使 用 外 键 。 任 意 一 张 关系 表 的 主键 可 以 设计 为 男 一 
张 关 系 表 的 外 键 。 在 表示 类 间 的 零 或 一 关联 时 ， 外 键 必须 设计 在 “可 选 ”的 关系 表 中 ， 这 样 
可 以 避免 出 现 数据 库 设计 者 不 愿 看 到 的 空 引用 。 

例如 ， 考 虑 “客户 ”拥有 “ 借 记 卡 ” 这 种 关系 中 的 零 或 一 关联 关系 ( 见 图 15-16 中 的 静 
态 模型 )。 在 关系 数据 库 设 计 中 ，customerId 被 选 作 “客户 ” 表 的 主键 而 сагата 被 选 作 “ 借 记 
卡 ” 表 的 主键 。 

Customer ( customerName，customerId，customerAddress ) 


因为 不 是 每 一 个 客户 都 有 借 记 卡 〈 可 选 关 系 )， 因 此 将 cardd 作为 “客户 ” 表 的 外 键 可 
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能 会 导致 某 些 客户 的 卡号 为 空 值 。 另 一 方面 ， 每 张 借 记 卡 必然 为 某 个 客户 所 有 (一 对 一 关 
系 )， 因 此 将 customerld 作为 “ 借 记 卡 ” 表 中 的 外 键 是 


最 佳 的 选择 ， 因 为 它 永远 不 会 产生 空 值 。 因 此 ， 
customerld 被 选 作 “ 借 记 卡 ” 表 的 外 键 ， 并 代表 了 客 б» 
户 和 借 记 卡 表 之 间 的 关联 关系 。 customerAddress: String 


Debit Card ( саг 4, PIN, expirationDate, status, 
customerld ) 

(下 划 线 表示 主键 ,斜体 表示 外 刍 ) 

2. 将 一 对 多 关联 映射 到 外 键 

在 设计 具有 一 对 多 关联 的 数据 库 关系 结构 时 ， 需 
要 将 外 键 放 在 处 于 “多 ”的 一 方 的 关系 表 中 。 考 虑 
“客户 ”拥有 “账户 ”关系 的 一 对 多 关联 ， 如 图 15-15 





所 示 。 在 关系 数据 库 的 设计 中 ， 处 于 “一 ”的 一 方 的 pr 
关系 数据 表 ( 客户 ) 的 主键 被 设计 为 处 于 “多 ”的 一 limit: Real 


total: Real 





方 的 关系 数据 表 ( 账户 ) 的 外 键 。 
在 这 个 例子 中 ，customerld 是 “客户 ” 表 的 主键 。 №1516 ИЯ (FRX) 
Customer ( сиѕіотегМате, customerld, customerAddress ) 
accountNumber 是 “账户 ” 表 的 主键 ， 而 customerld 是 “账户 ” 表 的 外 键 。 

Account ( accountNumber, balance, customerld ) 
在 这 个 例子 中 ， 由 于 每 个 账户 都 会 有 一 个 客户 (一 对 一 关系 )， 所 以 外 键 customerld 总 能 

对 应 到 一 个 客户 。 如 果 将 “客户 ” 表 中 的 accountNumber 设置 为 外 键 ， 那么 鉴于 一 个 客户 可 能 

会 有 多 个 账户 (一 对 多 关系 )， 因 此 需要 一 个 列表 来 保存 外 键 。 而 在 关系 表 中 不 允许 存在 属性 

列表 ， 因 为 这 样 会 导致 层次 结构 ， 与 关系 数据 库 中 表 的 扁平 化 〈 非 层次 化 ) 设计 原则 相 冲 突 。 


15.7.4 将 关联 类 映射 到 关联 表 


关联 类 表示 两 个 或 多 个 类 之 间 的 关联 关系 ， 通 常用 于 表示 多 对 多 关联 。 关 联 类 需要 被 映 
射 为 关联 表 。 一 个 关联 表 表 示 两 个 或 多 个 关系 之 间 的 关联 。 关 联 表 的 主键 是 一 个 复合 键 ， 由 
参与 关联 的 关系 表 的 主键 组 成 。 

例如 ， 在 图 15-17 的 静态 模型 中 ,“ 小 时 数 ”( Hours ) 关联 类 表示 “项 目 ”( Project) 
ЖЖ “Ж А” (Employee) 类 之 间 的 关联 。“ 小 时 数 ” 类 有 一 个 属性 ， 即 “工作 小 时 数 ” 
( hoursWorked )， 表 示 一 个 雇员 在 某 个 项 目 上 工作 的 时 间 。 


Employee 


employeeName: String 













projectid: String 
projectName: String 
startDate: Date 
endDate: Date 
customer: String 





i 4 Is staffed by 


hours Worked: Real 


PA 15-17 将 关联 类 映射 到 关联 表 
每 个 实体 类 都 会 被 映射 为 一 张 关 系 表 ， 其 中 也 包括 Hours 关联 类 ，Hours 关联 类 被 设 






level: String 
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计 为 一 张 被 称 为 Hours 的 关联 表 。 在 关系 数据 库 设计 中 ，projectld 被 选 为 “项 目 ” 表 的 主 
键 ，employeeld 被 选 为 “雇员 ” 表 的 主键 ， 这 两 个 主键 构成 了 Hous 关联 表 的 一 个 复合 主 
键 ( projectId，employeeld )。 这 两 个 属性 都 是 外 键 : projectid 可 以 让 我 们 从 Hours 表 导 航 到 
Project 表 ; 而 employeeld 可 以 让 我 们 从 Hours 表 导 航 到 Employee 表 。 这 些 表 的 设计 如 下 : 

Project ( projectld, projectName ) 

Employee (employeeld, employeeName, employeeAddress ) 

Hours (projectld, employeeld, hoursWorked ) 


15.7.5 ”将 整体 / 部 分 关系 映射 到 关系 数据 库 


整体 /部 分 关系 是 组 合 或 者 聚合 关系 ， 它 包含 了 代表 组 合 或 聚合 类 的 一 个 实体 类 以 及 代 
表 部 分 类 的 两 个 或 多 个 实体 类 。 当 把 整体 / 部 分 关系 映射 为 一 个 关系 数据 库 时 ， 聚 合 或 复合 
类 ( 整体 部 分 ) 和 每 个 部 分 类 都 要 被 设计 为 一 张 关系 表 。 

整体 关系 表 (复合 或 聚合 关系 ) 的 主键 是 由 部 分 关系 表 的 以 下 某 一 项 构成 的 : 

e 部 分 表 的 主键 : 当 整 体 类 和 部 分 类 之 间 存 在 一 对 一 关联 关系 时 。 

e 部 分 表 的 复合 主键 的 一 部 分 : 当 整 体 类 和 部 分 类 之 间 存 在 一 对 多 关联 关系 时 。 

о 部 分 表 的 外 键 : 当 部 分 表 并 不 需要 用 复合 主键 来 唯一 确定 表 中 某 一 行 ， 并且 整体 类 和 

部 分 类 之 间 存 在 一 对 多 关联 关系 时 。 

例如 ， 考 虑 一 个 静态 模型 ( 见 图 15-18) 中 的 聚合 关系 。 该 静态 模型 包括 一 个 “学 院 ” 
(College) 聚合 (整体 ) 类 以 及 “ 系 ”( Department ) “行政 办 公 室 ”( Admin Осе) 和 “研究 
中 心 ”( Research Center) 三 个 部 分 类 。 在 关系 数据 库 的 设计 中 ， 聚 合 表 的 主键 是 “学 院 名 称 ” 
(collegeName )。 对 于 “行政 办 公 室 ”部 分 表 ， 它 与 “学 院 ” 表 具 有 一 对 一 关联 关系 ， 其 主键 也 
是 “学 院 名 称 ”。 部 分 表 “ 系 ”与 “学 院 ” 表 具有 一 对 多 关联 关系 。 由 于 我 们 假设 “部 门 名 称 ” 
( departmentName ) 可 以 唯一 地 确定 一 个 部 门 ， 因此“ 学院 名 称 ” 不 会 作为 复合 主键 的 属性 。 
但 是 ,“ 学 院 名 称 ” 却 是 它 的 外 键 ， 因 为 这 样 可 以 从 分 表 “ 系 ”导航 到 聚合 表 “ 学 院 ”: 

College ( collegeName ) 

Admin Office ( collegeName, location ) 

Department ( departmentName, collegeName, location ) 


collegeName: String 
dean: String 
VY 











Admin Office 


location: String deptName: String name: String 
phone#: String deptLocation: String location: String 
administrator: String deptPhone#: String 

chairPerson: String 

secretary: String 


foundingDate: Date 
renewalDate: Date 


图 15-18 将 整体 /部 分 关系 映射 到 关系 表 
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15.7.6 ”将 泛 化 / 特 化 关系 映射 到 关系 数据 库 


有 三 种 将 泛 化 / 特 化 关系 映射 到 关系 数据 库 的 方法 : 

° 每 个 父 类 和 子 类 都 分 别 映射 为 一 张 关 系 表 

е 只 将 子 类 映射 为 关系 表 

e 只 将 父 类 映射 为 关系 表 

1. 将 父 类 和 子 类 映射 到 关系 表 

父 类 和 每 个 子 类 都 映射 为 一 张 关 系 表 。 它 们 共享 主键 的 属性 ， 换 言 之 ， 父 类 和 子 类 产生 
的 关系 表 拥 有 相同 的 主键 。 

该 方法 主要 的 优势 在 于 简洁 和 可 扩展 ， 这 是 因为 每 个 类 都 会 映射 为 一 张 表 。 然 而 ， 最 大 
的 劣势 在 于 父 类 / 子 类 之 间 的 导航 比较 慢 ， 尤 其 是 每 次 访问 父 类 时 都 需要 再 访问 子 类 (为 了 
访问 子 类 的 某 些 属性 )， 这 样 对 数据 库 访 问 的 次 数 会 翻 倍 。 

此 外 ， 这 种 设计 方法 需要 在 父 类 中 显 式 地 定义 子 类 的 区 分 属性 ， 用 于 确定 泛 化 关系 中 的 
抽象 性 质 。 尽 管 在 静态 模型 中 并 没有 显 式 地 定义 子 类 区 分 属性 , 但 是 在 数据 库 中 的 父 类 表 中 
需要 使 用 它 来 确定 应 该 导航 到 哪个 子 类 表 中 。 

ZE “IKE” (Account) 父 类 和 “支票 账户 ”( Checking Account) 子 类 与 “储蓄 账户 ” 


( Savings Account) 子 类 的 例子 ( 如 图 15-19 
中 的 静态 模型 所 示 )。 在 关系 数据 库 设计 中 ， 
А 








“账户 ” 父 类 的 属性 变 成 “账户 ” 表 的 属性 ， 
其 主键 为 accountNumber。 此 外 ， 子 类 区 分 
属性 accountType 也 被 作为 “账户 ” 表 的 属 


性 。 父 类 表 的 主键 也 被 加 入 到 各 子 类 表 中 作 ыы 
为 它们 的 主键 。 因 此 ， 和 “账户 ” 表 一 样 ， 


“支票 账户 ” 表 和 “储蓄 账户 ” 表 拥 有 相 | 
同 的 主键 accountNumber, Е, 6727 3 图 15-19 SRE TEE RN ees 
假设 账户 号 是 唯一 的 。 


Account ( accountNumber，accountType，balance ) 









Checking Account ( accountNumber, lastDepositAmount ) 

Savings Account ( accountNumber, interest ) 

2. 只 将 子 类 映射 到 关系 表 

第 二 种 设计 方法 是 只 将 子 类 映射 为 关系 表 。 使 用 这 种 方法 的 话 ， 每 个 子 类 都 会 对 应 一 张 
K, 但 是 没有 对 应 于 父 类 的 表 。 父 类 的 属性 在 每 个 子 类 表 中 重复 出 现 。 使 用 该 方法 最 好 的 情 
况 是 子 类 属性 比较 多 而 父 类 属性 比较 少 。 此 外 ， 应 用 程序 需要 知道 查询 哪个 子 类 表 。 

针对 账户 泛 化 / 特 化 层次 结构 的 例子 ， 考 虑 只 将 子 类 映射 为 关系 数据 库 的 情况 ， 如 静态 
模型 所 示 ( 图 15-19 )。 在 关系 数据 库 设计 中 ， 存 在 两 张 子 类 表 ， 即 “支票 账户 ”( Checking 
Account) 表 和 “储蓄 账户 ”( Savings Account) #, 没有 父 类 表 。 父 类 的 两 个 属性 “账户 号 ” 
和 “余额 ”在 每 个 子 类 表 中 重复 出 现 ，accountNumber 是 每 个 子 类 表 的 主键 。“ 支 票 账 户 ” 表 
包含 了 两 个 继承 而 来 的 “账户 ”属性 (accountNumber, balance) 以 及 特定 于 支票 账户 的 属性 ， 
即 “ 最 后 一 次 取款 金额 ”( lastDepositAmount )。“ 人 储蓄 账户 ” 表 包 含 了 两 个 继承 而 来 的 “ 账 
户 ” 属 性 以 及 特定 于 储蓄 账户 的 属性 ， 即 “利率 ”( interest )。 
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Checking Account ( accountNumber, balance, lastDepositAmount ) 

SavingsAccount ( accountNumber, balance, interest ) 

只 将 子 类 映射 为 关系 数据 库 的 方法 经 常 被 用 来 提高 数据 库 的 访问 速度 ， 因 为 该 方法 避免 
了 前 文 所 述 的 父 类 表 与 子 类 表 之 间 的 导航 。 

3. 只 将 父 类 映射 到 关系 表 

第 三 种 设计 方法 是 只 将 父 类 映射 为 关系 数据 表 。 在 该 方法 中 ， 只 有 一 张 父 类 表 而 
不 存在 子 类 表 ， 所 有 子 类 的 属性 都 放 到 父 类 表 中 。 在 父 类 表 中 需要 添加 子 类 区 分 属性 
(accountType )。 父 类 表 中 的 每 一 行 都 会 描述 某 个 子 类 的 属性 ， 而 与 该 子 类 无 关 的 属性 都 设 为 
空 值 。 当 父 类 的 属性 非常 多 而 子 类 的 属性 以 及 子 类 数量 很 少时 ( 例如 两 到 三 个 ) 可 以 用 这 种 
方法 。 

针对 “账户 泛 化 / 特 化 层次 结构 ”的 例子 ， 考虑 只 将 父 类 映射 为 关系 表 的 情况 ， 如 静态 
模型 所 示 ( 图 15-19 )。 在 关系 数据 库 设计 中 只 存在 一 张 “ 账 户 ” 表 而 没有 其 他 子 类 表 。 两 
个 子 类 “支票 账户 ”和 “储蓄 账户 ”的 属性 都 集成 到 “账户 ” 表 中 。“ 账 户 ” 表 有 一 个 主 
Ж accountNumber,“ 余 额 ”( balance ) 也 作为 该 表 的 属性 。 此 外 ， 表 中 还 包含 一 个 子 类 区 分 
属性 accountType， 用 来 区 分 账户 类 型 。“ 支 票 账户 ” 子 类 的 属性 ( 即 “ 最 后 一 次 取款 金额 ” 
(lastDepositAmount )) 以 及 “储蓄 账户 ” 子 类 的 属性 ( 即 “ 利 率 ”( interest )) 都 被 集成 到 
“账户 ” 表 中 。 


Account (accountNumber, accountType, balance, lastDepositAmount, interest ) 
15.8 总结 


本 章 介绍 了 客户 端 /服务 器 软件 体系 结构 的 设计 。 在 基于 客户 端 /服务 体系 结构 模式 的 体 
系 结构 中 ,由 单 服务 器 和 多 客户 端 构成 的 体系 结构 最 为 简单 。 该 模式 有 多 种 变 体 ， 将 在 后 续 
章节 中 介绍 。 此 外 ,在 设计 客户 端 / 服 务 器 体系 结构 时 需要 考虑 一 些 设 计 决 策 ， 例 如 某 个 服 
务 需 要 被 设计 为 顺序 性 的 还 是 并 发 的 子 系统 、 客 户 端 和 服务 器 子 系统 之 间 需 要 使 用 何 种 通信 
模式 等 。 第 16 章 所 介绍 的 面向 服务 的 体系 结构 、 第 17 章 所 介绍 的 基于 构件 的 软件 体系 结构 
都 包含 了 客户 端 /服务 器 体系 结构 。 在 第 21 章 中 会 展示 一 个 客户 端 /服务 器 软件 体系 结构 的 
案例 研究 ， 即 “银行 系统 ”。 本 章 还 介绍 了 如 何 将 静态 模型 映射 到 数据 库 包装 器 类 和 关系 数据 
库 中 。 文 献 Rumbaugh et al. ( 1991, 2005) 和 Blaha and Premerlani ( 1998) 中 对 从 静态 模型 
到 关系 数据 库 映 射 有 更 详细 的 介绍 。 此 外 ， 标 准 的 数据 库 教科 书 中 也 给 出 了 更 多 关于 关系 数 
据 库 设计 的 知识 ， 如 Silberschatz, Korth, and Sudarshan (2010) 的 教材 。 


练习 


选择 题 ( 每 道 题 选 择 一 个 答案 ) 

1. 什么 是 服务 器 ? 

(a ) 一 个 服务 于 客户 的 软 硬 件 系统 

(b) 发 送 请 求 并 等 待 响应 的 子 系统 

(с) 响应 客户 端 请 求 的 子 系 统 

(4) 向 多 个 客户 端 提供 一 个 或 多 个 服务 的 软 硬 件 系 统 
2. 基本 的 客户 端 / 单 服务 体系 结构 模式 是 指 : 
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(а) 多 个 客户 端 请 求 服务 ， 多 个 服务 完成 客户 端 请 求 

Cb) 多 个 客户 端 请 求 服 务 ， 一 个 服务 完成 客户 端 请 求 

(с) 一 个 客户 端 请 求 服务 ， 一 个 服务 完成 客户 端 请 求 

(а) 一 个 客户 端 请 求 服务 ， 多 个 服务 完成 客户 端 请 求 

3. 一 个 多 层 客户 端 /服务 器 体系 结构 模式 中 ， 以 下 哪个 关于 中 间 层 的 描述 是 正确 的 ? 
(a) 中 间 层 是 客户 端 层 (b) 中 间 层 是 服务 层 

(е) 中 间 层 既是 控制 层 也 是 服务 层 (4) 中 间 层 既是 客户 端 层 也 是 服务 层 
4. 多 客户 端 /多 服务 体系 结构 模式 与 多 客户 端 / 单 服务 体系 结构 模式 的 区 别 何在 ? 
(a) 一 个 服务 可 以 接收 来 自 多 个 客户 端的 请 求 

(b) 一 个 客户 端 可 以 向 多 个 服务 发 送 请 求 

(с) 一 个 客户 端 可 以 向 其 他 客户 端 发 送 请 求 

(а) 一 个 服务 可 响应 来 自 多 个 客户 端的 请 求 

5. 一 个 顺序 性 服务 是 如 何 设计 的 ? 


(а) 响应 客户 端 请 求 的 一 个 对 象 (b) 响应 客户 端 请 求 的 多 个 对 象 

(с) 响应 客户 端 请 求 的 一 个 子 系统 (d) 响应 客户 端 请 求 的 多 个 子 系统 
6. 一 个 并 发 服务 是 如 何 设计 的 ? 

(а) 响应 客户 端 请 求 的 一 个 对 象 (b) 响应 客户 端 请 求 的 多 个 对 象 

(с) 响应 客户 端 请 求 的 一 个 子 系统 (а) 响应 客户 端 请 求 的 多 个 子 系统 


7. 什么 是 数据 库 包装 器 类 ? 
(a) 封装 数据 结构 的 类 
(b) 封装 数据 库 的 类 
(с) 封装 如 何 访问 数据 库 中 的 数据 的 细节 的 类 
(а) 封装 一 个 关系 表 的 类 
8. 将 一 个 实体 类 设计 为 一 个 关系 表 时 ， 以 下 哪个 不 正确 ? 


(a) 关系 表 有 多 个 主键 (b) 关系 表 有 多 个 外 键 
(с) 关系 表 有 一 个 主键 (4) 关系 表 有 一 个 复合 主键 
9. 将 一 个 聚合 层次 结构 映射 到 关系 表 时 ， 以 下 哪个 不 正确 ? 
(а) 聚合 表 和 部 分 表 有 不 同 的 主键 (b) 聚合 表 和 部 分 表 有 相同 的 主键 276 
(с) 聚合 表 的 主键 是 部 分 表 的 外 键 (4) 部 分 表 的 主键 是 聚合 表 的 外 键 


10. 将 一 个 泛 化 / 特 化 关系 映射 到 关系 数据 库 时 ， 以 下 哪个 不 正确 ? 
(a) 父 类 和 每 个 子 类 都 被 设计 为 关系 表 (b) 只 有 子 类 被 设计 为 关系 表 
(с) 聚合 类 和 部 分 类 都 被 设计 为 关系 表 (d) 只 有 父 类 被 设计 为 关系 表 277 
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设计 面向 服务 的 体系 结构 





面向 服务 的 体系 结构 ( Service-Oriented Architecture, SOA ) 是 一 个 由 多 个 自治 的 服务 组 
成 的 分 布 式 软件 体系 结构 。 这 些 服 务 是 分 布 式 的 ， 因 此 它们 可 以 在 不 同 的 结 点 上 运行 并 且 由 
不 同 的 服务 提供 者 来 提供 。 使 用 面向 服务 的 体系 结构 的 目标 是 开发 由 分 布 式 服务 组 成 的 软件 
应 用 ， 使 得 各 个 服务 能 够 在 不 同 的 平台 上 运行 并 且 能 够 用 不 同 的 语言 来 实现 。 面 向 服务 的 体 
系 结构 使 用 标准 的 协议 以 支持 服务 之 间 的 通信 和 信息 交换 。 为 了 使 应 用 能 够 发 现 服务 并 与 服 
务 进 行 通信 ， 每 一 个 服务 都 有 一 个 服务 描述 。 这 些 服务 描述 定义 了 服务 的 名 字 、 服 务 的 位 置 
以 及 服务 的 数据 交换 要 求 ( Erl 2006, 2009 )。 

一 个 服务 提供 者 所 提供 的 服务 可 以 被 多 个 客户 端 所 使 用 。 通 常 ， 一 个 客户 端 会 与 由 某 个 
服务 提供 者 提供 的 服务 签约 ， 例 如 因特网 服务 、 电 子 邮 件 服务 和 网 络 电话 〈Voice over Internet 
Protocol, VoIP) 服务 。 在 客户 端 /服务 器 体系 结构 中 ， 一 个 客户 端 与 一 个 特定 的 、 由 一 个 固 
定 的 服务 器 配置 提供 的 服务 进行 通信 ， 与 此 不 同 的 是 ， 本 章 所 描述 的 面向 服务 的 体系 结构 建 
立 在 松 耦 合 服务 的 概念 基础 上 ， 这 些 服务 在 服务 代理 的 协助 下 能 够 被 客户 端 ( 也 被 称 为 服务 
消费 者 或 服务 请 求 者 ) 发 现 和 连接 。 

本 章 描 述 了 如 何 设计 面向 服务 的 体系 结构 、 如 何 设 计 服 务 以 及 如 何 复 用 服务 。 本 章 还 简 
要 地 描述 了 面向 服务 的 体系 结构 的 支持 技术 。 然 而 ， 由 于 技术 的 变化 十 分 迅速 而 概念 则 更 加 
持久 ， 因 此 本 章 更 加 关注 于 设计 面向 服务 的 体系 结构 的 概念 、 方 法 和 模式 。 本 章 描述 了 支持 
面向 服务 的 体系 结构 、 服 务 设计 和 服务 复 用 的 软件 体系 结构 模式 。 

16.1 节 描 述 面向 服务 的 体系 结构 的 概念 、 体 系 结构 和 模式 。16.2 节 描 述 软件 体系 结构 代 
理 者 模式 。16.3 节 描 述 面向 服务 的 体系 结构 的 支持 技术 ， 这 部 分 是 通过 Web 服务 来 实现 的 。 
16.4 节 描 述 软件 体系 结构 事务 模式 。16.5 节 描 述 协商 模式 。16.6 节 描 述 服务 接口 设计 。16.7 
节 描 述 服务 协调 。16.3 节 描 述 面 向 服务 的 体系 结构 设计 。 最 后 ，16.9 节 描 述 服务 复 用 。 


16.1 面向 服务 的 体系 结构 的 概念 、 体 系 结构 和 模式 


面向 服务 的 体系 结构 的 一 个 重要 目标 是 把 服务 设计 为 自治 的 、 可 复 用 的 构件 。 服 务 意 在 
自 包 含 和 松 耦 合 ， 这 就 意味 着 服务 之 间 的 依赖 尽量 最 小 化 。 当 需要 访问 多 个 服务 并 且 对 这 些 
服务 的 访问 需要 进行 排序 的 时 候 ， 可 以 使 用 协调 服务 而 不 是 让 一 个 服务 直接 依赖 于 另外 一 个 
服务 。 本 章 介绍 了 几 种 针对 面向 服务 的 应 用 的 软件 体系 结构 模式 : 代理 者 模式 ， 包 括 服务 注 
册 、 服 务 代理 和 服务 发 现 〈【16.2 节 ); 事务 模式 ， 包 括 两 阶段 提交 事务 模式 、 复 合 事务 模式 和 
长 事务 模式 〈16.4 节 ) 协商 模式 ( 16.5 № )。 


服务 的 设计 原则 


服务 需要 根据 几 个 关键 的 原则 来 设计 (Ен 2006, 2009 )。 其 中 许多 概念 都 是 良好 的 软件 
工程 和 设计 的 原则 ， 这 些 都 已 经 结合 到 面向 服务 的 体系 结构 的 设计 中 。 
о 松 耦 合 。 服 务 之 间 应 该 相对 独立 。 因 此 ， 一 个 服务 所 拥有 的 关于 其 他 服务 的 信息 能 够 
最 小 化 ， 并 且 在 理想 情况 下 应 该 不 依赖 于 其 他 服务 。 
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© 服务 契约 。 一 个 服务 提供 了 一 个 契约 ， 面 向 服务 的 体系 结构 应 用 可 以 依赖 于 这 种 服务 
契约 。 通 常情 况 下 ， 该 契约 以 一 组 操作 的 形式 在 服务 接口 中 进行 定义 。 每 个 操作 通常 
有 输入 和 输出 参数 ， 但 是 也 可 以 包含 服务 质量 参数 ， 例 如 响应 时 间 和 可 用 性 。 这 个 原 
则 建立 在 一 些 面向 对 象 设计 思想 基础 上 ， 包 括 接口 与 实现 分 离 以 及 将 接口 作为 服务 提 
供 者 和 服务 使 用 者 之 间 的 契约 。 

治 。 每 个 服务 都 是 自 包含 的 ， 这 使 得 服务 能 够 在 不 需要 其 他 服务 的 情况 下 独立 运 
行 。 这 一 思想 能 够 通过 服务 与 服务 间 的 协调 机 制 相 分 离 的 方式 来 实现 ， 这 使 得 服务 之 
间 不 需要 直接 通信 。 
抽象 。 就 像 在 面向 对 象 设计 中 那样 ， 服 务 的 细节 是 被 隐藏 的 。 每 个 服务 仅仅 以 所 提供 
的 操作 的 方式 暴露 服务 接口 以 及 每 个 操作 所 需要 的 输入 和 所 返回 的 输出 。 

可 复 用 性 。 面 向 服务 的 体系 结构 的 一 个 关键 目标 是 设计 可 复 用 的 服务 。 前 述 的 服务 设 
计 目 标 意 在 促进 复 用 。 
• 可 组 合 性 。 服 务 被 设计 为 能 够 组 合成 更 大 的 复合 服务 。 在 一 些 情况 下 ， 一 个 复合 服务 

也 需要 提供 个 体 服务 之 间 的 协调 。 

ө 无 状态 性 。 在 可 能 的 情况 下 ， 服 务 几乎 不 保持 任何 关于 特定 客户 端 活动 的 信息 。 
• 可 发 现 性 。 服 务 通过 一 种 外 部 描述 使 其 可 以 被 某 种 发 现 机 制 所 发 现 。 


16.2 ”软件 体系 结构 代理 者 模式 


在 面向 服务 的 体系 结构 中 ， 对 象 代 理 者 扮演 着 客户 端 和 服务 的 中 介 者 角色 。 代 理 者 使 得 
客户 端 不 再 需要 知道 某 个 服务 在 哪里 提供 以 及 如 何 获 得 这 个 服务 。 复 杂 的 代理 者 提供 了 白 页 
(命名 服务 ) 和 黄页 ( 交易 服务 )， 使 得 客户 端 可 以 方便 地 定位 服务 。 

在 代理 者 模式 中 ( 也 被 称 为 对 象 代理 或 者 对 象 请 求 代理 模式 )， 代 理 者 扮演 着 客户 端 和 服 
务 之 间 的 中 介 角 色 。 服 务 向 代理 者 注册 。 客 户 端 通过 代理 者 定位 服务 。 在 代理 者 代理 了 客户 
端 和 服务 之 间 的 连接 之 后 ， 客 户 端 和 服务 之 间 的 通信 可 以 直接 进行 或 者 通过 代理 者 进行 。 

代理 者 同时 提供 了 位 置 透明 和 平台 透明 。 位 置 透明 是 指 如 果 服 务 移动 到 一 个 新 的 位 置 ， 
那么 客户 端 不 会 察觉 到 这 个 移动 而 只 有 代理 者 需要 得 到 通知 。 平 台 透 明 是 指 每 个 服务 能 够 在 
不 同 的 硬件 / 软件 平台 上 运行 并 且 不 需要 维持 其 他 服务 运行 的 平台 信息 。 

客户 端 通过 基于 代理 的 通信 ( 而 不 是 通过 给 定 服务 的 位 置 ) 来 向 代理 者 查询 所 提供 的 服务 。 
首先 ， 服 务 要 向 一 个 代理 者 注册 ， 就 像 16.2.1 节 中 所 介绍 的 服务 注册 模式 所 描述 的 那样 。 客 户 端 
知道 所 请 求 的 服务 而 不 是 其 位 置 ， 这 种 通信 模式 被 称 为 白 页 代理 ， 类 似 于 电话 目录 中 的 白 页 。 
16.2.2 节 中 的 代理 者 转发 模式 和 16.2.3 节 中 的 代理 者 句柄 模式 描述 了 这 类 模式 。 在 黄页 代理 中 ， 特 
定 的 服务 并 不 被 事先 知道 而 需要 被 发 现 ， 这 将 在 16.2.4 节 中 介绍 。 a | 

aBroker 


16.2.1 服务 注册 模式 
在 服务 注册 模式 中 ， 服 务 需要 向 代理 者 注册 服务 信息 ， 包 


R2: 
registrationAck 






括 服务 名 称 、 服 务 描述 和 提供 服务 的 位 置 。 服 务 注册 在 服务 第 BENS 
一 次 加 入 到 代理 交易 所 ( 类 似 于 股票 交易 所 ) 时 被 执行 。 在 此 Service 


之 后 ， 如 果 服 务 重新 定位 ， 它 需要 向 代理 者 重新 注册 并 提供 它 
的 新 位 置 。 服 务 注册 模式 如 图 16-1 所 示 ， 其 中 描述 了 服务 按照 
以 下 消息 顺序 向 一 个 代理 者 注册 或 者 重新 定位 后 的 重新 注册 : 图 16-1 服务 向 代理 者 注册 
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R1: 服务 向 代理 者 发 送 一 个 “注册 服务 ”(register Service) 的 请 求 。 


R2: 代理 者 在 服务 库 中 注册 服务 ， 并 且 向 服务 发 送 一 个 “注册 确认 ”( registration Аск), 





16.2.2 ”代理 者 转发 模式 


代理 者 可 以 以 多 种 方式 处 理 客户 端的 请 求 。 在 代理 者 转发 模式 中 ， 客 户 端 发 送 一 条 标识 
它 所 请 求 的 服务 的 消息 ， 例 如 从 一 个 指定 的 银行 提取 现金 。 代 理 者 收 到 客户 端的 请 求 后 ， 确 定 
服务 的 位 置 ( 服务 所 位 于 的 结 点 ID )， 然 后 将 消息 转发 给 位 于 该 位 置 上 的 服务 。 消 息 到 达 服 务 
后 ， 所 请 求 的 服务 被 调用 。 代 理 者 收 到 服务 响应 并 将 其 转发 回 给 客户 端 。 这 个 模式 在 图 16-2 
中 描述 ， 它 由 以 下 的 消息 序列 组 成 : 

1) 客户 端 (服务 请 求 者 ) 向 代理 者 发 送 一 个 服务 请 求 。 

2) 代理 者 查询 服务 的 位 置 并 且 将 请 求 转发 给 合适 的 服务 。 

3) 服务 执行 请 求 并 且 将 回复 发 送 给 代理 者 。 


4) 代理 者 将 回复 转发 给 客户 。 
Ба 
© 


2: forwardedRequest 
4 ~ 
3:serviceRepl 
А. forwardedReply py 


aServiceRequester ЕЗ 


代理 者 转发 模式 提供 了 客户 端 和 服务 之 间 消 息 转 发 的 中 介 。 由 于 每 条 消息 都 能 够 被 审 
查 ， 因 此 这 种 模式 潜在 地 提供 了 高 度 的 安全 性 。 然 而 ， 与 基本 的 客户 端 /服务 器 模式 相 比 
( 见 15.1 节 )， 这 种 安全 性 是 以 性 能 为 代价 而 获得 的 。 这 是 因为 消息 的 通信 和 量 加 倍 了 ， 通 过 
代理 者 从 客户 端 到 服务 的 通信 需要 四 条 消息 ， 而 客户 端 与 服务 之 间 的 直接 通信 和 则 只 需要 两 条 
消息 。 


16.23 ”代理 者 句柄 模式 


代理 者 句柄 模式 保持 了 位 置 透明 的 好 处 ， 同 时 增加 了 减少 消息 通信 量 的 优势 。 代 理 者 返 
回 给 客户 端 一 个 用 于 和 服务 之 间 直 接 通信 的 服务 句柄 ， 而 不 是 转发 每 条 客户 端 消息 给 服务 。 
当 客 户 端 和 服务 之 间 很 可 能 存在 对 话 并 且 需 要 交换 多 条 消息 的 时 候 ， 该 模式 特别 有 用 。 这 个 
模式 在 图 16-3 中 描述 ， 它 由 以 下 的 消息 序列 组 成 : 






1: serviceRequest 






р 
~ 


图 16-2 代理 者 转发 ( 白 页 ) 模式 
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B1: serviceRequest 


2 


4 
{2 В2: serviceHandle 


eae pm | 


图 16-3 ”代理 者 句柄 (НИ) 模式 






B3: serviceRequestWithHandle 
—> 


< 一 一 = 
B4: serviceReply 


: 客户 端 ( 服 务 请 求 者 ) 向 代理 者 发 送 一 个 服务 请 求 。 
: 代理 者 查询 服务 的 位 置 并 且 向 客户 端 返 回 一 个 服务 句柄 。 


: 客户 端 使 用 服务 句柄 来 请 求 合 适 的 服务 。 
: 服务 执行 请 求 并 且 直 接 发 送 回复 给 客户 端 。 





如 果 客 户 端 和 服务 之 间 很 可 能 存在 对 话 并 且 交 换 多 条 消息 ， 那 么 这 个 方法 比 代理 者 转发 
更 加 有 效 。 这 是 因为 代理 者 句柄 中 与 代理 者 的 交互 只 在 开始 对 话 的 时 候 发 生 一 次 ， 而 不 是 像 
代理 者 转发 中 那样 每 次 都 发 生 。 大 多 数 商 业 对 象 代理 者 都 使 用 代理 者 句柄 的 设计 。 使 用 这 种 
方法 ， 在 对 话 结束 之 后 丢弃 句柄 是 客户 的 责任 。 使 用 一 个 过 时 的 句柄 容易 失败 ， 这 是 因为 服 
务 可 能 在 这 期 间 移动 了 位 置 。 如 果 一 个 服务 确实 移动 了 ， 它 需要 通知 代理 者 使 得 代理 者 能 够 
更 新 名 字 表 。 


16.2.4 ”服务 发 现 模 式 


在 此 前 介绍 的 代理 者 通信 模式 中 ， 客 户 端 知道 请 求 的 服务 而 不 是 位 置 ， 这 些 模式 被 称 
为 白 页 代理 。 另 一 种 代理 模式 是 黄页 代理 ， 类 似 于 电话 目录 中 的 黄页 ， 在 这 种 模式 中 客户 
端 知 道 请 求 的 服务 类 型 而 不 是 特定 的 服务 。 这 个 模式 ( 如 图 16-4 所 示 ) 也 被 认为 是 服务 
发 现 模式 ， 因 为 它 允 许 客户 端 发 现 新 的 服务 。 客 户 端 发 送 一 个 查询 请 求 给 代理 者 ， 请 求 一 
个 给 定 类 型 的 所 有 服务 。 代 理 者 回复 一 个 满足 客户 端 请 求 的 所 有 服务 的 列表 。 客 户 端 ( 可 
能 是 在 咨询 用 户 之 后 ) 选择 一 个 特定 的 服务 。 代 理 者 返回 一 个 服务 句柄 ， 客 户 端 使 用 该 句 
柄 与 服务 直接 通信 。 这 个 模式 交互 先 有 一 个 黄页 请 求 再 有 一 个 白 页 请 求 ， 其 更 详细 的 描述 
如 下 : 

1) 客户 端 ( 服务 请 求 者 ) 发 送 一 个 黄页 请 求 给 代理 者 ， 请 求 所 有 给 定 类 型 的 服务 的 信息 。 

2 ) 代理 者 查询 这 个 信息 ， 返 回 满足 查询 标准 的 所 有 服务 的 列表 。 

3) 客户 端 选择 一 个 服务 ， 发 送 一 个 白 页 请 求 给 代理 者 。 

4) 代理 者 查询 服务 的 位 置 ， 返 回 一 个 服务 句柄 给 客户 端 。 

5) 客户 端 使 用 服务 句柄 请 求 合适 的 服务 。 

6) 服务 执行 请 求 ， 直 接 发 送 响应 给 客户 端 。 
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7 
# 2: serviceList 


1: queryServices 


3: select 
aService Z 


L 7 4: service 
aService 
Requester 


Handle 
16.3 面向 服务 的 体系 结构 的 技术 支持 


尽管 面向 服务 的 体系 结构 在 概念 上 是 与 平台 无 关 的 ， 但 是 当前 的 Web 服务 技术 平台 对 它 
们 的 支持 非常 成 功 。 一 个 Web 服务 是 一 个 使 用 标准 的 因特网 和 基于 XML 的 协议 访问 的 服务 。 
283] 本 节 简 要 介绍 基于 Web 服务 实现 的 面向 服务 的 体系 结构 的 支持 技术 。 


16.3.1 Web 服务 协议 











5: serviceRequestWithHandle 
一 一 > 





< -n 
6: serviceReply 


16-4 ”服务 发 现 ( 黄页 ) 模式 


| aService | 


应 用 客户 端 和 服务 需要 一 个 通信 协议 来 进行 构件 间 的 通信 。 可 扩展 标记 语言 (Extensible 
Markup Language, XML ) 是 一 种 允许 不 同 的 系统 通过 交换 数据 和 文本 进行 互 操作 的 技术 。 简 
单 对 象 访问 协议 (Simple Object Access Protocol, SOAP ) 是 一 种 由 万 维 网 联盟 (W3C) Я 
计 的 轻 量 级 协议 ， 该 协议 建立 在 XML Al HTTP 的 基础 上 ， 支 持 分 布 式 环境 下 的 信息 交换 。 
SOAP 定义 了 一 个 发 送 XML 编码 数据 的 统一 方法 ， 由 三 部 分 组 成 : 一 个 信封 ， 定 义 了 一 个 描 
述 消 息 内 容 以 及 消息 处 理 方 式 的 框架 ; 一 组 编码 规则 ， 描 述 了 特定 应 用 的 数据 类 型 实例 ; 一 
个 表示 远程 过 程 调用 和 响应 的 协定 。 


16.3.2 Web 服务 


应 用 为 客户 端 提供 服务 。 一 个 应 用 服务 的 例子 是 使 用 万 维 网 进行 应 用 间 通 信 的 Web 服 
务 。 从 软件 的 角度 来 看 ，Web 服务 是 为 万 维 网 上 的 不 同 软件 应 用 之 间 提 供 了 标准 通信 手段 的 
应 用 程序 接口 (API )。 从 业务 应 用 的 角度 来 看 ，Web 服务 是 一 种 企业 通过 在 因特网 上 的 直接 
服务 的 形式 提供 给 其 他 公司 或 者 程序 使 用 的 业务 功能 。 一 个 Web 服务 由 一 个 服务 提供 者 提 
供 ， 并 且 可 以 由 其 他 服务 组 合 而 成 并 形成 新 的 服务 和 应 用 。 图 16-5 给 出 了 一 个 Web 客户 调用 
一 个 Web 服务 的 例子 。 

目前 已 有 的 一 些 构件 技术 支持 基于 构件 技术 和 Web 服务 的 软件 应 用 构造 ， 包 括 .NET、 
J2EE、WebSphere 和 WebLogic。 


16.3.3 注册 服务 


注册 服务 用 于 使 得 服务 能 够 被 其 客户 端 所 找到 。 服 务 通过 一 个 注册 服务 进行 注册 ， 这 一 
过 程 称 为 发 布 或 者 注册 。 大 多 数 代理 者 ( 例如 CORBA 和 Web 服务 代理 者 ) 提供 了 一 个 注册 
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服务 。 对 于 Web 服务 ， 服 务 库 被 提供 用 于 支持 基于 万 维 网 的 服务 发 布 和 定位 。 服 务 提供 者 将 
服务 和 服务 描述 注册 到 服务 库 中 。 寻 找 服务 的 客户 端 能 够 通过 在 服务 库 中 查询 找到 合适 的 服 
务 。Web 服务 描述 语言 ( Web Services Description Language, WSDL ) 是 一 种 基于 XML 的 语 
言 ， 用 于 描述 一 个 服务 做 什么 、 它 在 哪里 和 如 何 调 用 它 。 


Web 服 务 请 求 者 结 点 Web 服 务 提供 者 结 点 
| 


Ея = aWebService 


1: webService 2: webService | 
Request Response М 





Е 16-5 在 一 个 万 维 网 服务 应 用 中 的 Web 客户 端 和 Web 服务 


16.34 ”代理 和 发 现 服务 


在 分 布 式 环境 中 ， 对 象 代理 者 是 客户 端 和 服务 之 间 交 互 的 中 介 。 一 个 代理 技术 的 例子 是 
Web 服务 代理 者 。 关 于 Web 服务 的 信息 能 够 通过 用 于 Web 服务 集成 的 统一 描述 、 发 现 和 集成 
( Universal Description, Discovery and Integration, UDDI ) 框架 来 定义 。 一 个 UDDI 规约 由 几 
个 相关 的 文档 和 一 个 XML 模式 组 成 ， 该 XML 模式 定义 了 一 种 基于 SOAP 的 用 于 Web 服务 
注册 和 发 现 的 协议 。Web 服务 代理 者 可 以 使 用 UDDI 框架 为 客户 端 提供 一 种 在 Web 上 动态 发 
现 服务 的 机 制 。 

图 16-6 展示 了 一 个 Web 客户 端 向 一 个 Web 服务 代理 者 发 送 Web 服务 发 现 请 求 的 例子 ， 
它 使 用 了 代理 者 句柄 模式 (1 )。 代 理 者 确定 一 个 满足 客户 端 需求 的 特定 的 Web 服务 作为 响应 
(2 )。Web 客户 端 发 送 一 个 请 求 给 所 发 现 服务 的 Web 服务 (3 )。 


Web 服 务 请 求 者 结 点 Кес. ш 












1: webServiceDiscovery { | webService 4: webService | 
еди Request Response Al 





图 16-6 Web 服务 代理 者 示例 


16.4 软件 体系 结构 事务 模式 


服务 经 常会 封装 数据 或 者 为 需要 由 客户 端 读 取 或 更 新 的 数据 提供 访问 。 许 多 服务 所 提供 
的 更 新 操作 都 需要 进行 协调 。 本 节 描 述 了 如 何 使 用 事务 和 事务 模式 来 达到 这 个 目的 。 
事务 是 客户 端 对 由 两 个 或 者 更 多 操作 组 成 的 服务 的 请 求 ， 这 些 操作 属于 同一 个 逻辑 功能 
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并 且 必 须 全 部 完成 或 者 全 部 不 做 。 事 务 在 客户 端 生成 并 且 发 送 给 服务 处 理 。 对 于 原子 〈 即 不 可 


分 的 ) 事务 ， 服 务 需 要 能 够 启动 事务 、 提 交 事 务 或 者 终止 事务 。 事 务 通常 用 于 要 求 原 子 性 的 分 
布 式 数据 库 的 更 新 ， 例 如 从 一 个 银行 的 账户 转账 到 另 一 个 银行 的 账户 。 这 种 方法 可 以 对 分 布 式 
数据 库 的 更 新 进行 协调 ,使 得 相关 操作 要 么 全 部 被 执行 ( 提交 ) 要 么 全 部 被 回 滚 〈 终 止 )。 
一 个 事务 必须 全 部 完成 或 者 完全 不 做 。 考 虑 银行 间 电 子 资金 转账 的 例子 。 对 于 一 个 被 认 
为 完成 的 事务 ， 它 的 所 有 操作 必须 被 成 功 地 执行 。 如 果 事 务 中 的 任何 一 个 操作 不 能 被 执行 ， 
这 个 事务 必须 被 终止 。 这 就 意味 着 已 经 完成 的 各 个 操作 需要 被 撤销 ， 使 得 一 个 被 终止 的 事务 
的 影响 就 像 这 个 事务 从 来 没有 发 生 过 一 样 。 
事务 有 以 下 的 特性 ， 有 时 被 称 为 ACID 特性 : 
e 原子 性 (А). 一 个 事务 是 一 个 不 可 分 割 的 工作 单元 ， 要么 全 部 完成 ( 提交 ) 要 么 全 部 
Aik (HŽ) 
e 一 致 性 ( C )。 一 个 事务 执行 完 之 后 ， 系 统 必须 处 于 一 致 的 状态 。 
о 隔离 性 ( 1 )。 一 个 事务 的 行为 必须 不 能 被 其 他 事务 所 影响 。 
o 持续 性 ( D )。 一 个 事务 完成 之 后 ， 它 的 修改 是 持久 性 的 。 即 使 在 发 生 系统 故障 的 情况 
下 ， 事 务 所 做 出 的 修改 也 能 够 持久 存在 。 这 种 特性 也 被 称 为 持久 性 。 


16.4.1 两 阶段 提交 协议 模式 


两 阶段 提交 协议 模式 处 理 在 分 布 式 系统 中 管理 原子 性 事务 的 问题 。 考 虑 两 个 银行 事务 的 
例子 。 

1) 提 款 事务 。 一 个 提 款 事务 能 够 在 一 个 操作 内 被 处 理 。 此 时 ， 需 要 使 用 信和 号 量 来 进行 
同步 ， 以 确保 对 于 客户 账户 记录 的 访问 是 互 斥 的 。 事 务 处 理 器 可 以 对 这 个 客户 账户 记录 加 锁 ， 
对 该 记录 进行 更 新 ， 然 后 解锁 。 

2) 转账 事务 。 考 虑 一 个 两 个 账户 之 间 的 转账 事务 ， 例 如 从 一 个 储蓄 账户 到 一 个 支票 账户 
并 且 这 两 个 账户 属于 两 个 不 同 的 银行 ( 服务 )。 该 转账 事务 必须 记 入 储蓄 账户 的 借方 和 支票 账 
户 的 贷方 。 因 此 ， 转 账 事务 是 由 借方 和 贷方 这 两 个 原子 性 的 操作 组 成 的 ， 并 且 转 账 事务 必须 
要 么 被 提交 要 么 被 终止 : 

• 被 提交 。 借 方 和 贷方 操作 都 发 生 了 。 

ө 被 终止 。 借 方 和 贷方 操作 都 没有 发 生 。 

实现 这 一 结果 的 一 个 方法 是 使 用 两 阶段 提交 协议 ， 该 协议 可 以 对 分 布 式 应 用 中 不 同 结 点 
上 的 更 新 进行 同步 。 两 阶段 提交 协议 的 结果 是 事务 要 么 被 提交 ( 此 时 所 有 的 更 新 都 成 功 了 ) 
要 么 被 终止 (此 时 所 有 的 更 新 都 失败 了 )。 

事务 的 协调 由 “提交 协调 者 ”( Commit Coordinator) 提供 。 每 个 结 点 都 有 一 个 参与 方 的 
服务 。 在 银行 转账 事务 中 有 两 个 参与 方 :“ 第 一 个 银行 的 服务 ”( first Bank Service), FHA 
转账 的 “ 转 出 账户 ”( Кот Account); “第 二 个 银行 的 服务 ”( second Bank Service )， 管 理 着 转 
账 的 “ 转 入 账户 ”( to Account )。 在 两 阶段 提交 协议 的 第 一 个 阶段 (图 16-7 ),“ 提 交 协 调 者 ” 
发 送 一 个 “准备 提交 ”( prepare To Commit) 的 消息 (1а, 1b) 给 每 个 参与 方 服务 。 每 个 参与 
方 服务 锁 住 相关 记录 ( 1a.1、1b.1 )， 执 行 借方 或 贷方 更 新 ( 1a.2、1b.2 )， 然 后 发 送 一 条 “ 准 
备 好 提交 ”(ready To Commit) 的 消息 (1a.3, 1b.3) 给 “提交 协调 者 ”"。 如 果 一 个 参与 方 服务 
无 法 执行 更 新 ， 那 么 会 发 送 一 条 “拒绝 提交 ”( refuse To Commit) 的 消息 。 提 交 协 调 者 等 待 
来 自 所 有 参与 方 的 响应 。 
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: CommitCoordinator 














та: prepareTo 1b.3: readyTo 
Commit Commit 
ni a.3: readyTo 1b: оне 
Commit Commit 





firstBankService 


1а.1: lock | 
1а.2: debit 


secondBankService 


1b.1: lock 
1b.2: credit 









图 16-7 两 阶段 提交 协议 的 第 一 个 阶段 示例 : 银行 转账 


当 所 有 的 参与 方 服务 都 做 出 了 响应 之 后 , “提交 协调 者 ”进入 两 阶段 提交 协议 的 第 二 个 
阶段 (图 16-8 )。 如 果 所 有 的 参与 方 都 发 送 了 “准备 好 提交 ”( ready To Commit) 的 消息 ， 那 
么 “提交 协调 者 ”发 送 “ 提 交 ”( commit ) 消息 (2а, 2Ь) 给 所 有 参与 方 服务 。 每 个 参与 方 服 
务 做 出 持久 性 的 更 新 (2a.1、2b.1 )， 解锁 记录 ( 2a.2、2b.2 )， 并 且 发 送 “ 完 成 提交 ”( commit 
Completed ) 的 消息 (2a.3、2b.3 ) 给 “提交 协调 者 ”"。“ 提 交 协 调 者 ”等 待 所 有 参与 方 “ 完 成 


提交 ”的 消息 。 
一 


2а.3: Commit 2b: Commit 
Completed 









20.3: Commit 


Se 


secondBankService 


2b.1: confirmCredit | 
25.2: unlock 


2а: ше» 


firstBankService 


2a.1: confirmDebit | 
2а.2: unlock 













图 16-8 ”两 阶段 提交 协议 的 第 二 个 阶段 示例 : 银行 转账 


如 果 一 个 参与 方 服务 以 “准备 好 提交 ”的 消息 响应 “准备 提交 ”的 消息 ， 那 么 表示 其 承 
诺 要 完成 这 个 事务 。 即 使 参与 方 服 务 发 生 了 延迟 ( 例如 ， 在 发 送 “ 准 备 好 提交 ”的 消息 后 宕 
机 了 )， 它 也 必须 完成 这 个 事务 。 另 一 方面 ， 如 果 任 何 一 个 参与 方 服务 以 “拒绝 提交 ”的 消息 
响应 “准备 提交 ”的 消息 ， 那 么 “提交 协调 者 ”会 发 送 一 个 “终止 ”( abort ) 消息 给 所 有 参与 
者 。 于 是 所 有 参与 者 对 更 新 进行 回 滚 。 
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1642 ”复合 事务 模式 


此 前 的 银行 转账 交易 是 一 个 扁平 事务 的 例子 ， 具 有 “全 有 或 全 无 ”的 特性 。 相 反 ， 一 个 
复合 事务 可 能 仅仅 需要 部 分 回 深 。 当 客户 











3: hotelReservation 





端的 事务 需求 能 够 被 分 解 成 更 小 的 扁平 原 on 
子 性 事务 ， 而 且 每 个 原子 性 事务 能 够 被 单 ReservationService 
独 执 行 和 回 滚 时 ， 可 以 使 用 复合 事务 模 4: flightReservation 
式 。 例 如 ， 如 果 一 个 旅游 代理 商 预订 了 机 ТЫ 
预订 看 作 由 三 个 扁平 事务 组 成 的 复合 事务 
是 更 加 灵活 的 处 理 方式 。 将 事务 看 作 一 个 — || ResevationSeviee 
复合 事务 可 以 允许 预订 的 部 分 被 改变 或 者 ако 
取消 而 不 影响 预订 的 其 他 部 分 。 

5: carReservation 
明 复合 事务 模式 。 旅 游 代理 商 为 一 个 客户 surconmatdtNs 
进行 旅程 规划 ， 由 机 票 预订 (1、2 )、 宾 
馆 预 订 (3、4 ) 和 租车 预订 (5、6 ) 组 成 。 
事务 ， 那 么 每 个 事务 可 以 独立 处 理 。 因 图 16-9 复合 事务 模式 示例 
此 ， 宾 馆 预 订 可 以 独立 于 机 票 预订 和 租车 
预订 而 从 一 个 宾馆 调整 到 另 一 个 宾馆 。 当 然 ， 在 某 些 情 况 下 ， 例 如 这 个 行程 被 延迟 了 或 者 取 
消 了 ， 所 有 的 三 个 预订 都 不 得 不 被 调整 。 


票 ， 接 着 又 预订 了 宾馆 和 租车 ， 那 么 将 该 
TravelAgent 
图 16-9 通过 旅游 代理 商 的 例子 来 说 
RentalService 
如 果 旅 程 的 三 个 部 分 被 看 成 是 单独 的 扁平 
16.4.3 ”长 事务 模式 


长 事务 是 一 种 有 人 参与 其 中 、 需 要 很 长 甚至 可 能 无 限 长 的 时 间 来 执行 的 事务 ， 这 是 因为 
每 个 人 的 行为 是 不 可 预知 的 。 在 涉及 与 人 之 间 的 交互 的 事务 中 ， 在 人 考虑 各 种 选项 的 同时 长 
时 间 地 锁 住 记录 是 不 受 欢迎 的 。 例 如 ， 在 使 用 扁平 事务 的 机 票 预 订 中 ， 记 录 会 在 事务 期 间 被 
锁 住 。 由 于 事务 中 有 人 的 参与 ， 因 此 记录 可 能 会 被 锁 住 几 分 钟 。 在 这 种 情况 下 ， 使 用 长 事务 
模式 会 更 好 ， 它 可 以 将 一 个 长 事务 分 成 两 个 或 者 更 多 的 单独 的 事务 (通常 是 两 个 ), 使 得 人 的 
决策 发 生 在 连续 的 事务 对 之 间 ( 例如 第 一 个 和 第 二 个 之 间 )。 

在 机 票 预订 的 例子 中 ， 首 先 通 过 一 个 “查询 ”( query ) 事务 显示 可 用 的 座位 ， 然 后 执行 
“预订 ”( reserve ) 事务 。 按 照 这 种 方法 的 话 ， 在 做 出 预订 之 前 还 要 重新 检查 座位 是 否 可 用 。 
因为 多 个 代理 商 可 能 会 同时 查询 同一 个 航班 ， 所 以 在 查询 时 显示 可 用 的 座位 可 能 在 预订 时 就 
不 再 可 用 了 。 如 果 航 班 只 有 一 个 座位 是 可 用 的 ， 那 么 只 有 第 一 个 代理 商 能 够 订 到 这 个 座位 。 
需要 注意 的 是 即使 航空 公司 允许 座位 超 订 ,但 是 显然 允许 预订 的 座位 数量 仍然 是 有 限 的 ， 
此 这 个 问题 依然 存在 。 

这 个 方法 可 以 通过 旅游 代理 商 的 例子 在 图 16-10 中 说 明 。 旅 游 代 理 商 首先 查询 航空 公司 的 
预订 服务 (1а, 1b, 1с) 来 确定 可 用 的 航班 。 三 个 预订 服务 都 积极 地 回复 了 可 用 的 座位 (та, 
lb.1、1c.1 )。 在 考虑 各 种 选项 并 咨询 客户 之 后 ， 旅 游 代 理 商 向 Unified 航空 公司 的 预订 服务 发 
出 了 “预订 ”请 求 (2 )。 由 于 没有 在 记录 上 加 锁 ， 该 预订 不 再 可 用 ， 因 此 预订 服务 回复 了 一 个 
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“拒绝 ”( reject ) 的 响应 (response ) ( 3 )。 于 是 旅游 代理 商 按照 第 二 个 选项 ( Вр Britannic 航空 
公司 ) 预订 了 航班 (4 )。 这 次 预订 服务 回复 了 一 个 预订 被 接受 的 “确认 ”( confirm ) 响应 (5 )。 


1а; 
flightQuery 








unifiedAirlines 
ReservationService 


1а.1: 
response 





2: ы ~ 


3: 
reject 1b: 4: 


query reserve 
worldWide = brittanicAirways 
TravelAgent ReservationService 
query 


virtualAtlantic 
ReservationService 


图 16-10 长 事务 模式 示例 












16.1: 
геѕропѕе 





1с.1: 
response 


16.5 ”协商 模式 


在 有 些 面 向 服务 的 体系 结构 中 ， 服 务 之 间 的 协调 机 制 中 包含 软件 主体 (agent) 之 间 的 协 


商 ， 从 而 使 得 它们 能 够 共同 做 出 决策 。 在 协商 模式 ( 也 被 称 为 基于 主体 的 协商 或 者 多 主体 协 
商 模 式 ) 中 ， 一 个 客户 主体 代表 用 户 向 一 个 服务 主体 发 起 一 个 服务 提议 。 服 务 主体 尝试 着 满 
足 客户 的 提议 ， 这 个 过 程 可 能 涉及 与 其 他 服务 的 通信 。 确 定 了 可 用 的 选项 后 ， 服 务 主体 向 客 
户主 体 提 出 一 个 或 者 多 个 与 客户 主体 的 提议 最 接近 的 选项 。 在 此 基础 上 ， 客 户主 体 可 以 选择 
向 其 中 的 一 个 选项 发 出 请 求 、 提 出 更 多 的 选项 或 者 拒绝 。 如 果 服 务 主 体能 够 满足 客户 主体 的 
请 求 ， 那 么 就 接受 请 求 ; 否则 ， 服 务 主 体 拒绝 请 求 。 


以 下 通信 服务 为 软件 主体 之 间 的 互相 协商 提供 了 支持 ( Pitt et al. 1996 ): 

客户 主体 作为 客户 的 代表 ， 可 以 做 以 下 事情 : 

ө 提出 一 个 服务 。 客 户主 体 向 一 个 服务 主体 提出 一 个 服务 。 这 个 提出 的 服务 是 可 以 协商 
的 ， 意 味 着 客户 主体 愿意 考虑 还 价 。 

e 请 求 一 个 服务 。 客 户主 体 向 一 个 服务 主体 请 求 一 个 服务 。 这 个 请 求 的 服务 是 不 可 协商 
的 ， 意 味 着 客户 主体 不 愿意 考虑 还 价 。 

о 拒绝 一 个 服务 报价 。 客 户主 体 拒 绝 服务 主体 提出 的 报价 。 

服务 主体 代表 着 服务 ， 可 以 做 以 下 事情 : 

© 报价 一 个 服务 。 作 为 对 客户 提议 的 响应 ， 一 个 服务 主体 提出 一 个 还 价 。 

е 拒绝 一 个 客户 请 求 /提议 。 服 务 主体 拒绝 客户 主体 提出 的 或 者 请 求 的 服务 。 

e 接受 一 个 客户 请 求 / 提议。 服务 主体 接受 客户 主体 提出 的 或 者 请 求 的 服务 。 


协商 模式 示例 


考虑 以 下 这 个 涉及 一 个 客户 主体 和 一 个 软件 旅游 主体 的 例子 ， 其 中 的 场景 与 现实 世界 中 游 
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2a: flightQuery 


unifiedAirlines 
ReservationService 


a. response 
1: propose (tripToLondon, 


return 21 Oct., <$700) 277 6: гејес! 
4: request (UA $750) 
8: request (BA $775) 
worldWide brittanicAirways 
TravelAgent ReservationService 
virtualAtlantic 
ReservationService 
Я 16-11 协商 模式 示例 


一 一 > 
所 一 一 一 
3: offer (UA $750, BA $775)! 
7: reject, 
11: accept 

客 和 旅游 代理 商 的 交互 场景 相似 。 这 个 例子 使 用 了 协商 模式 和 长 事务 模式 。 在 这 个 旅游 代理 商 
的 例子 中 ， 客 户主 体 通过 对 象 代 理 者 的 黄页 ( 图 16-4) 发 现 了 一 个 合适 的 服务 旅游 主体 ， 这 里 
假设 选择 了 “环球 旅游 代理 ”( world Wide Travel Agent )。 接 下 来 客户 主体 代表 一 个 用 户 开 始 了 
一 次 协商 过 程 。 该 用 户 希 望 坐 飞机 从 华盛顿 到 伦敦 ， 出 发 日 期 为 10 月 14 日 ， 返 回 日 期 为 10 月 
21 日 ， 价 格 为 低 于 700 美元 。 这 个 协商 过 程 用 一 个 通信 图 表示 ( 见 图 16-11 )， 它 的 描述 如 下 : 

1) “РЕЖ” (Client Agent ) 使 用 “提议 ”( propose ) 服务 来 提出 带 有 指定 约束 的 到 伦 
敦 的 旅程 。 

2 )“ 环 球 旅游 代理 ”确定 了 三 个 航空 公司 ， 即 Britannic 航空 公司 (ВА). Unified 航空 公司 
(UA ) 和 Virtual Atlantic 航空 公司 ( VA )， 提 供 从 华盛顿 到 伦敦 的 航线 。 接 着 向 三 家 航空 公司 的 
服务 ( 即 “UA 服务 ”( 2a )、 “ВА 服务 ”(2b ) ЯП “VA 服务 ”(2c ))， 发 送 了 一 个 “航班 查询 ” 
(flight Query ) 来 查询 给 定 日 期 的 航班 ， 然 后 收 到 三 家 公司 的 服务 所 回复 的 航班 时 间 和 价格 。 

3) “环球 旅游 代理 ”发 送 一 个 符合 所 提出 的 价格 要 求 的 可 用 航班 的 “报价 ”( offer ) 消息 
给 “客户 主体 "。 如 果 可 用 的 机 票 报价 都 高 于 客户 的 要 求 ,“ 环 球 旅游 代理 ”就 选择 所 能 找到 的 
最 便宜 的 航班 。 在 这 种 情况 下 ， 它 确定 了 满足 提议 的 日 期 的 两 个 最 好 报价 是 UA 的 750 美元 的 
航班 和 BA 的 775 美元 的 航班 。 因 为 没有 低 于 700 美元 的 航班 , “环球 旅 游 代理 ”提出 了 最 接 
近 于 提议 报价 的 可 用 航班 。 因 此 ， 它 发 送 UA 的 750 美元 的 航班 的 报价 消息 给 “客户 主体 ”。 

4 )“ 客 户主 体 ” 向 用 户 显示 选项 。 接 下 来 ,“ 客 户主 体 ” 可 能 会 “请 求 ”(request ) 一 个 服务 
(例如 ， 请求 服务 主体 所 给 出 的 一 个 选项 )。 或 者 ， 如 果 用 户 不 喜欢 所 提供 的 所 有 选项 并 且 “ 提 议 ” 
(propose ) 一 个 新 的 日 期 要 求 ， 那 么 “客户 主体 ”将 “拒绝 ”( reject ) 服务 报价 。 在 我 们 这 个 例子 
中 ， 用 户 选 择 了 UA 的 报价 ,“ 客 户主 体 ” 向 “环球 旅游 代理 ”发 送 了 UA 航班 的 “请 求 ”消息 。 

5 )“ 环 球 旅 游 代理 ”向 UA 服务 发 出 “预订 ”( reserve ) 请 求 。 

6) 假设 航班 不 再 可 用 ，UA 服务 拒绝 了 预订 请 求 。 

7) 由 于 航班 不 再 可 用 ,“ 环 球 旅游 代理 ”以 “拒绝 ”的 消息 回复 了 “客户 主体 ”。 

8)“ 客 户主 体 ” 请 求 了 下 一 个 最 佳 报价 ， 即 BA 的 775 美元 的 航班 ， 然 后 发 送 “ 请 







5: reserve 




















2b: query 9: reserve 
— 


2b.1: response 10: confirm 












2c: query 


2с.1: joo 
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Ж” ВА 航班 的 消息 给 “环球 旅游 代理 ”。 

9 )“ 环 球 旅游 代理 ”向 ВА 服务 发 出 了 “预订 ”请 求 。 

10) 假设 航班 依然 可 用 ，BA 服务 确认 了 该 预订 。 

11) “环球 旅游 代理 ”向 “客户 主体 ”回复 了 一 个 接受 消息 。 

在 这 个 例子 中 ， 需 要 注意 的 是 “环球 旅游 代理 ”在 与 “客户 主体 ”通信 时 扮演 着 服务 的 
角色 ， 而 在 与 航空 公司 服务 通信 时 扮演 着 客户 端的 角色 。 


16.6 面向 服务 体系 结构 中 的 服务 接口 设计 


应 用 COMET 方法 设计 新 的 服务 首先 需要 应 用 在 第 8 章 中 介绍 的 对 象 结构 组 织 准则 。 在 
动态 交互 建 模 过 程 中 确定 客户 端 对 象 和 服务 对 象 之 间 的 交互 。 用 于 服务 操作 设计 的 方法 类 似 
于 第 14 章 中 所 介绍 的 类 接口 设计 方法 。 发 送 到 服务 的 消息 形成 了 服务 操作 设计 的 基础 。 通 过 
分 析 这 些 消息 可 以 确定 操作 的 名 称 以 及 输入 和 输出 参数 。 

作为 一 个 例子 ， 考 虑 在 第 22 章 中 所 介绍 的 在 线 购物 系统 的 面向 服务 的 体系 结构 案例 
研究 。 图 16-12 展示 了 客户 从 供应 商 购 买 商 品 的 例子 。 这 个 通信 图 描述 了 “处 理 配 送 订单 ” 
( Process Delivery Order) 用 例 的 实现 ， 其 中 涉及 两 个 服务 ， 即 “配送 订单 服务 ”( Delivery 
Order Service ) 和 “库存 服务 ”( Inventory Service )。 









«service» 
: Inventory 
Service 


DS: Check жалккан | | D6: Item Info 
D11: Reserve Items 012: Items Reserved 


D2: Order Request, 
D10: Reserve Inventory 




















D1, D9: Supplier Input 
D8: Order Output, 


«user interaction» =» «coordinator» 
: SupplierInteraction < aSupplierCoordinator 
D7: Order Info, 
D14: Inventory Output D13: Inventory Status 


aSupplier 


D3: Select Order у 1 D4: Selected Order 


«service» 
: DeliveryOrder 
Service 


FA 16-12 “处 理 配 送 订 单 ” 用 例 的 通信 图 


每 个 服务 的 操作 都 是 通过 分 析 发 送 给 服务 的 消息 请 求 来 确定 的 。 在 图 16-12 中 关于 “处 
理 配 送 订单 ”的 通信 图 所 描述 的 对 象 交互 中 ， 有 一 条 消息 (D5 ) 发 送 给 “库存 服务 ”来 检 
查 库存 ， 从 而 确定 送 货 订 单 中 的 物品 是 否 可 用 。 这 个 请 求 被 设计 为 操作 checkInventory， 它 
的 输入 参数 为 itemId， 它 的 输出 参数 为 inventoryStatus， 相 应 的 消息 为 D6。 第 二 条 发 送 给 
“库存 服务 ”的 请 求 是 保留 库存 ( 消息 D11 )。 这 个 请 求 被 设计 为 操作 reservelnventory, € 
的 输入 参数 为 itemId 和 amount。 这 个 保留 操作 等 同 于 准备 提交 库存 ， 对 应 于 两 阶段 提交 
协议 中 的 第 一 个 阶段 。 图 16-13 中 的 部 分 通信 图 描述 了 后 续 的 用 例 “ 确 认 出 货 ”( Confirm 
Shipment ) 和 “给 客户 开 账单 ”(Bill Customer) 中 的 一 些 对 象 。 其 中 有 一 条 消息 是 提交 库存 
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(消息 S9 )， 该 消息 将 引发 库存 更 新 以 确认 物品 被 移 除 、 打 包 和 出 货 。 这 个 请 求 被 设计 为 操作 
commitInventory， 它 的 输入 参数 是 itemId 和 amount， 对 应 于 两 阶段 提交 协议 中 的 第 二 个 阶 
段 。“ 库 存 服务 ”还 需要 额外 的 操作 来 终止 库存 (如 果 订 单 被 取消 和 库存 在 出 货 之 前 被 释放 ) 
并 更 新 库存 (补充 库存 )。 图 16-14 描述 了 “库存 服务 ”的 接口 〈 称 为 InventoryService )， 由 
Фе (Е checkInventory, ，reserveInventory 和 commitInventory 以 及 操作 update 和 abortInventory 
组 成 。 图 16-14 中 描述 的 “库存 服务 ”还 有 一 个 称 为 PInventoryService 的 供给 端口 ( 见 第 17 
章 )， 它 提供 了 名 为 IInventoryService 的 供给 接口 。 可 以 使 用 相似 的 分 析 过 程 来 确定 其 他 服务 
的 操作 。 第 22 章 中 给 出 了 完整 的 案例 研究 的 描述 。 













«service» 
: Inventory 
Service 


$10: Commit 
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«coordinator 
aSupplierCoordinator 


52: Ready For Shipment 


S9: Commit 1 
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$12: Supplier $11: Confirmation 
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«user interaction» 
: SupplierInteraction 





一 会 
$1: Supplier 
Input 
aSupplier 


Р 16-13 “确认 出 货 ” 和 “给 客户 开 账单 ”用 例 的 部 分 通信 图 


IInventoryService 






PInventoryService 
«interface» 
IInventoryService 
SC 


checkInventory (in Нета, in amount, out inventoryStatus) 
update (in itemld, in amount) 

reservelnventory (in itemId, in amount, out inventoryStatus) 
commitInventory (in itemId, in amount, out inventoryStatus) 
abortInventory (in itemId, in amount, out inventoryStatus) 


Н 16-14 库存 服务 的 服务 接口 







«service» 
Inventory 
Service 






16.7 面向 服务 体系 结构 中 的 服务 协调 


涉及 多 个 服务 的 面向 服务 的 体系 结构 应 用 通常 需要 在 这 些 服务 之 间 进 行 协调 。 为 了 确保 
服务 之 间 的 松 看 合 ， 将 协调 的 实现 细节 和 各 个 服务 的 功能 相 分 离 会 比较 好 。 在 涉及 多 个 服务 
的 复杂 活动 中 ， 通 常 需要 通过 协调 机 制 来 控制 对 各 个 服务 的 访问 顺序 。 面 向 服务 的 体系 结构 
中 提供 了 不 同类 型 的 协调 机 制 ， 包 括 编制 (orchestration ) 和 编排 ( choreography )。 编 制 由 用 
于 协调 多 个 服务 的 采用 集中 式 控 制 的 工作 流 协调 逻辑 组 成 。 在 此 基础 上 可 以 通过 将 已 有 的 服 
务 引 入 到 新 的 服务 应 用 中 来 实现 服务 的 复 用 。 编 排 提供 了 服务 之 间 的 分 布 式 协调 ， 可 以 用 于 
不 同业 务 组 织 之 间 的 协调 。 因 此 ， 编 排 可 以 用 于 针对 来 自 不 同 服务 提供 商 、 由 不 同业 务 组 织 
提供 的 服务 之 间 的 协作 。 编 制 采 用 和 集中 式 控 制 ， 而 编排 采用 分 布 式 控制 。 

由 于 术语 编制 和 编排 经 常 互 换 使 用 ， 因 此 本 章 将 使 用 更 加 通用 的 术语 协调 来 描述 面向 服 
务 的 体系 结构 应 用 所 需要 的 针对 不 同 服务 的 顺序 控制 ， 而 不 管 所 采用 的 是 集中 式 控制 还 是 分 
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布 式 控制 。16.4 节 中 所 描述 的 事务 模式 可 以 被 用 于 服务 协调 。 

我 们 的 目标 是 让 服务 无 状态 ， 从 而 使 它们 的 可 复 用 性 更 好 。 有 些 时 候 ， 当 服务 必须 要 具有 
状态 信息 时 (例如 配送 订单 的 状态 )， 相 关 状 态 信 息 保 存在 配送 订单 记录 和 数据 库 中 。 当 需要 
配送 订单 状态 时 ， 可 以 从 配送 订单 记录 中 读 取 ( 或 进行 更 新 ， 如 果 需 要 的 话 )。 无 论 是 顺序 执 
行 还 是 并 发 执行 ,并且 无 论 是 否 是 状态 相关 的 ， 多 个 服务 调用 的 顺序 都 被 封装 在 协调 者 内 部 。 

图 16-12 和 16-13 给 出 了 一 个 协调 者 对 象 的 例子 ， 其 中 “供应 商 协调 者 ”(Supplier 
Coordinator ) 对 象 协调 了 “供应 商 交 互 ”( Supplier Interaction ) 对 象 与 “配送 订单 服务 ”和 “ 库 
存 服务 ”对 象 之 间 的 交互 。 “供应 商 协 调 者 ”提供 了 总 体 控 制 和 顺序 化 ， 这 就 是 所 谓 的 工作 流 。 

“供应 商 协 调 者 ”通过 供给 接口 ISupplierCoordinator 接收 来 自 “ 供 应 商 交 互 ”的 
供应 商 请 求 。“ 供 应 商 协调 者 ”是 “库存 服务 ”的 一 个 客户 端 ， 因 此 它 有 一 个 请 求 接口 
IInventoryService ( 图 16-14 )， 它 也 是 “配送 订单 服务 ”的 一 个 客户 。“ 供 应 商 协 调 者 ” 收 到 
的 来 自 于 “供应 商 交 互 ”的 请 求 是 : 

1 ) 请 求 需要 处 理 的 一 个 新 的 配送 订单 (图 16-12 中 的 消息 D2 )， 映 射 为 操作 requestOrder, 

2) 保留 库存 中 的 订单 项 (图 16-12 中 的 消息 D10 )， 了 映射 为 操作 reservelnventory, 

3) 识别 订单 已 经 准备 好 出 货 (图 16-13 中 的 消息 S2 )， 映 射 为 操作 readyForShipment, 

4) 订单 已 经 出 货 (图 16-13 中 的 消息 S14 )， 映 射 тее 
ВЕ confirmShipment. 

接口 ISupplierCoordinator Н БЖ 4 个 操作 组 成 ， 即 se хои 
$È 作 requestOrder, reserveInventory, readyForShipment requestOrder (in supplierld, out orderld) 

和 confirmShipment， 如 图 16-15 所 示 。 reservelnventory (in orderld, out inventoryInfo) 
图 16-15 “供应 商 协 调 者 ”的 协调 者 接口 







16.8 设计 面向 服务 的 体系 结构 


如 此 前 两 节 所 介绍 的 确定 服务 和 协调 者 的 接口 之 后 ， 就 可 以 开发 集成 的 通信 图 。 对 于 面 
向 服务 的 体系 结构 ， 这 个 图 既是 并 发 的 又 是 分 布 式 的 。 并 发 通信 图 展示 了 由 服务 参与 的 动态 
消息 顺序 以 及 服务 与 协调 者 构件 和 用 户 交互 构件 之 间 的 交互 。 一 个 并 发 通信 图 是 通过 整合 基 
于 用 例 的 通信 图 ( 就 像 在 第 13 章 中 描述 的 ) 和 定义 构件 与 服务 之 间 的 消息 通信 接口 来 开发 
的 。 对 于 与 服务 的 通信 方式 ， 同 步 通 信 是 最 常见 的 ， 这 是 因为 服务 需要 一 个 请 求 /响应 的 通 
信 。 然 而 ,也 可 以 使 用 带 回调 的 异步 消息 通信 (第 15 章 )。 对 于 点 对 点 的 通信 ， 例 如 两 个 协 
调 者 之 间 ， 可 以 使 用 异步 通信 。 

16-16 给 出 了 一 个 在 线 购物 系统 的 并 发 通信 图 ， 它 展示 了 每 个 用 户 交互 构件 ( “客户 
交互 ”( Customer Interaction) 和 “供应 商 交 互 ”( Supplier Interacion ))、 相 应 的 协调 者 构件 
(“客户 协调 者 ”( Customer Coordinator ) “供应 商 协调 者 ”( Supplier Coordinator ) 和 “账单 协 
调 者 ”( Billing Coordinator ) ) 以 及 六 个 服务 之 间 的 动态 消息 通信 。 在 线 购物 的 案例 研究 在 第 
22 章 中 介绍 。 大 多 数 的 服务 与 构件 之 间 的 通信 和 是 带 回复 的 同步 消息 通信 。 由 于 每 个 请 求 都 需 
要 一 个 响应 ， 因 此 这 种 通信 模式 在 面向 服务 的 体系 结构 中 经 常 被 使 用 。 这 种 模式 尤其 适合 用 
户 交 互 构 件 和 协调 者 ( 例如 “客户 交互 ”和 “客户 协调 者 ”之 间 ) 以 及 协调 者 和 服务 〈 例如 
“客户 协调 者 ”和 “目录 服务 ”( catalog Service)) 之 间 。 然 而 ， 协 调 者 ( 例如 “供应 商 协调 
者 ”和 “账单 协调 者 ”) 之 间 可 以 使 用 点 对 点 的 异步 消息 通信 ， 使 得 协调 者 不 必 等 待 响应 ; 如 
果 需 要 一 个 响应 ， 这 个 响应 也 是 异步 的 。 
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16.9 ”服务 复 用 


服务 设计 好 之 后 就 可 以 复 用 了 。 尽 管 一 个 服务 可 以 调用 另 一 个 服务 的 操作 ， 但 是 这 将 导 
致 该 服务 依赖 于 其 他 服务 ， 从 而 降低 该 服务 的 可 复 用 性 。 为 了 鼓励 服务 的 复 用 ， 我 们 建议 服 
务 一 般 应 该 只 有 供给 接口 而 没有 请 求 接口 〈 除非 使 用 了 带 回调 的 异步 通信 )， 这 样 会 使 得 服务 
更 加 独立 。 图 16-17 中 所 有 的 服务 都 遵循 了 这 个 方针 ， 即 只 有 供给 接口 而 没有 请 求 接口 。 


ICreditCardService 












PCreditCardService 


«interface» 
ICreditCardService 


«service» 
CreditCard 
Service 


ране е РА ee ee ы] 
authorizeCharge (in creditcardld, in amount, out authorizationResponse) 
commitCharge (in creditcardId, in amount, out chargeResponse) 
abortCharge (in creditcardId, in amount, out chargeResponse) 





ТЕта Service 


PEmailService 
«interface» 
ТЕта Зегмсе 
sendEmail (in emailld, in emailText) 


Р 16-17 “信用 卡 服务 ”和 “电子 邮件 服务 ”的 接口 


所 有 被 描述 的 服务 都 可 以 用 于 不 同 的 面向 服务 的 应 用 中 。 每 次 使 用 服务 开发 面向 服务 的 应 
用 时 都 要 创建 新 的 协调 者 对 象 ， 充 分 利用 所 提供 的 服务 ， 以 此 来 控制 和 排序 所 期 望 的 应 用 工作 
流 。 如 果 一 个 服务 得 到 了 复 用 ， 那 么 它 的 接口 是 已 知 的 ， 而 调用 该 服务 的 构件 ( 服务 的 客户 端 
或 协调 者 ) 应 当 确保 使 用 所 定义 的 操作 来 正确 地 调用 该 服务 ， 包 括 适 当 的 输入 和 输出 参数 。 此 
外 ， 操 作 调 用 有 时 还 需要 遵循 给 定 的 约束 ， 例 如 一 个 操作 是 否 需 要 在 另 一 个 操作 之 前 被 调用 。 

在 在 线 购物 系统 的 例子 中 ,“ 信 用 卡 服务 ”和 “电子 邮件 服务 ”是 两 个 被 复 用 的 服 
务 -“ 电 子 邮件 服务 ”是 两 个 服务 中 比较 简单 的 一 个 服务 ， 它 只 有 一 个 发 送 邮件 的 操作 ， 即 
sendEmail ( recipient, message )。 而 “信用 卡 服务 ” 则 需要 按照 预定 义 的 顺序 调用 两 个 服务 ， 
即 先进 行 交 易 授权 ( authorizeCharge )， 然 后 再 执行 交易 扣 款 ( commitCharge )。 此 外 ， 还 有 第 
三 个 操作 ， 即 终止 交易 〈abortCharge )。 


«service» 
Email 
Service 





16.10 BH 


本 章 介绍 了 如 何 设计 面向 服务 的 体系 结构 ， 包 括 如 何 设计 服务 和 如 何 复 用 服务 。 本 章 还 
简要 地 描述 了 面向 服务 的 体系 结构 的 支持 技术 ,但 更 关注 于 设计 面向 服务 的 体系 结构 的 相关 
概念 、 方 法 和 模式 ， 这 是 因为 技术 的 变化 十 分 迅速 而 概念 则 更 加 持久 。 服 务 也 可 以 被 设计 为 
一 个 分 布 式 的 基于 构件 的 软件 体系 结构 的 一 部 分 ， 就 像 在 下 一 章 中 描述 的 一 样 。 第 22 章 给 出 
了 设计 一 个 基于 面向 服务 的 体系 结构 的 在 线 购 物 系统 的 案例 研究 。 


练习 


选择 题 ( 每 道 题 选择 一 个 答案 ) 
1. 什么 是 面向 服务 的 体系 结构 (SOA) 7 
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(а) 一 个 由 多 个 相关 服务 组 成 的 分 布 式 软件 体系 结构 

(b ) 一 个 由 多 个 自治 服务 组 成 的 分 布 式 软件 体系 结构 

(с) 一 个 分 布 式 客户 端 / 服务 体系 结构 

(а) 一 个 分 布 式 软件 体系 结构 

2. 以 下 哪 一 个 特性 不 适用 于 服务 ? 

(a) 可 复 用 的 (b) 可 发 现 的 
(с) 固定 的 (d) 自治 的 
3. 在 面向 服务 的 体系 结构 中 ， 以 下 哪个 说 法 不 正确 ? 

(а) 一 个 客户 端 与 一 个 由 固定 服务 器 配置 提供 的 指定 服务 通信 
(b ) 一 个 客户 端 发 现 并 连接 到 一 个 服务 上 

(с) 多 个 客户 端 与 一 个 服务 通信 

(4) 使 用 标准 的 协议 来 实现 客户 端 与 服务 间 的 通信 
4. 什么 是 对 象 代理 者 ? 

(a) 一 个 间 人 系统 的 对 象 

(b) 一 个 向 其 他 对 象 发 送 请 求 的 对 象 

(с) 一 个 处 理由 其 他 对 象 所 发 送 的 请 求 的 对 象 

(а) 一 个 作为 客户 端 和 服务 之 间 的 交互 中 介 的 对 象 

5. 为 什么 服务 要 向 一 个 代理 者 注册 ? 

(a) 使 得 服务 请 求 者 可 以 发 现 它 (b) 使 得 服务 可 以 询问 代理 者 
(с) 使 得 注册 表 保 持 更 新 (4) 使 得 服务 能 够 被 重新 定位 
6. 什么 时 候 使 用 代理 者 句柄 模式 取代 代理 者 转发 模式 特别 有 用 ? 
(а) 如 果 客 户 端 只 与 服务 通信 一 次 

(b) 如 果 客 户 端 需要 与 服务 进行 一 次 对 话 

(с) 如 果 客 户 端 知道 所 需要 的 服务 的 类 型 而 不 知道 确切 的 服务 
(d) 如 果 客 户 端 需要 为 代理 者 提供 一 个 句柄 
7. 当 服务 请 求 者 满足 什么 条 件 时 黄页 代理 是 有 用 的 ? 

(a) 需要 发 现 服务 的 位 置 

(b ) 知道 所 需要 的 服务 的 类 型 而 不 知道 确切 的 服务 

(с) 知道 所 需要 的 确切 服务 而 不 知道 服务 的 类 型 


(d) 需要 发 现代 理 者 

8. 什么 是 事务 ? 

(а) 由 两 个 或 多 个 操作 组 成 (b) 由 一 个 操作 组 成 

(с) 由 两 个 或 多 个 不 可 分 割 的 操作 组 成 (4) 由 两 个 或 多 个 可 分 割 的 操作 组 成 
9. 什么 是 复合 事务 ? 

(a) 复合 事务 是 不 可 分 的 (b) 复合 事务 是 原子 性 的 

(c) 复合 事务 被 分 解 为 原子 性 事务 (а) 复合 事务 被 分 解 为 子 原子 性 事务 


10. 关于 协商 模式 ， 以 下 哪 一 个 说 法 不 正确 ? 
(a) 客户 主体 可 以 发 出 一 个 服务 提议 
(b ) 服务 主体 可 以 提供 一 个 服务 方案 报价 作为 对 一 个 客户 主体 的 服务 提议 的 响应 
(с) 客户 主体 可 以 请 求 一 个 服务 
(а) 服务 主体 可 以 提供 一 个 服务 方案 报价 作为 对 一 个 客户 主体 的 服务 请 求 的 响应 
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设计 基于 构件 的 软件 体系 结构 





在 基于 构件 的 分 布 式 软件 设计 中 ,我 们 为 分 布 式 应 用 设计 基于 构件 的 软件 体系 结构 。 我 
们 将 软件 应 用 划分 为 构件 ， 并 定义 构件 之 间 交 互 的 接口 。 为 此 ， 我 们 还 提供 了 如 何 确 定 构件 
的 指导 原则 。 构 件 需 要 以 一 种 可 配置 的 方式 进行 设计 ， 这 样 构件 的 实例 就 可 以 部 署 在 分 布 于 
不 同 地 理 位 置 的 多 个 结 点 上 。 

我 们 将 首先 按照 第 12 章 介绍 的 子 系统 组 织 准则 来 设计 构件 ， 然 后 ， 使 用 附加 的 构件 配置 
准则 来 保证 构件 确实 是 可 配置 的 一 一 换言之 ， 它 们 能 够 有 效 地 部 署 在 具有 不 同 地 理 位 置 结 点 
的 分 布 式 环境 中 。 

17.1 节 介 绍 基于 构件 的 分 布 式 软件 体系 结构 的 概念 、 体 系 结构 和 模式 。17.2 节 描 述 设 计 
基于 构件 的 分 布 式 软件 体系 结构 的 步骤 。17.3 节 描 述 复合 子 系统 和 构件 的 概念 和 设计 。17.4 
节 描 述 如 何 利 用 UML 对 构件 建 模 并 设计 构件 。17.5 节 描 述 将 分 布 式 应 用 构建 为 可 配置 的 分 布 
式 构件 的 构件 组 织 准则 。17.6 节 描 述 群 组 通信 (group communication ) 模式 ,包括 “广播 消 
息 通 信 ” 模 式 和 “订阅 /通知 消息 通信 ”模式 。 最 后 ，17.7 节 描 述 应 用 部 署 。 


17.1 基于 构件 的 软件 体系 结构 的 概念 、 体 系 结构 和 模式 


在 第 12 章 , 我 们 用 常规 方式 介绍 了 术语 “构件 ”。 本 章 描述 了 如 何 设计 基于 构件 的 分 
布 式 软件 体系 结构 中 的 分 布 式 构件 ， 还 描述 了 构件 组 织 准 则 ， 可 以 用 来 设计 在 分 布 式 配 置 
( distributed configuration ) 的 分 布 式 平台 上 部 署 并 执行 的 构件 。 本 章 还 使 用 具有 请 求 / 供给 接 
口 的 构件 端口 和 用 以 连接 兼容 端口 的 连接 器 (connector) 来 描述 构件 接口 的 设计 。 我 们 使 用 
复合 结构 图 (composite structure diagram ) 的 UML 表示 法 来 描述 基于 构件 的 软件 体系 结构 。 

之 前 提 到 的 体系 结构 通信 模式 可 以 用 于 这 种 软件 体系 结构 ， 包 括 同 步 、 异 步 和 代理 者 模 
式 。 另 外 ，17.6 节 描 述 的 群 组 通信 模式 也 可 以 使 用 。 

基于 构件 的 软件 体系 结构 的 一 个 重要 目标 是 提供 高 度 可 配置 的 基于 消息 的 并 发 设计 。 换 
言 之 ， 目 的 是 使 得 同一 个 软件 体系 结构 能 够 在 不 同 的 分 布 式 配置 上 进行 部 署 。 这 样 ， 对 一 个 
软件 应 用 进行 配置 时 ， 可 以 使 它 的 每 个 基于 构件 的 子 系统 都 各 自 部 署 到 其 独立 的 物理 结 点 上 ， 
也 可 以 使 它 所 有 的 抑或 是 部 分 的 构件 一 起 部 署 到 同一 物理 结 点 上 。 为 了 达到 这 种 灵活 性 ， 我 
们 需要 按照 如 下 方式 来 设计 软件 体系 结构 : 应 该 在 系统 部 署 而 非 系 统 设计 的 时 候 决定 哪个 构 
件 部 署 到 哪个 物理 结 点 上 。 

在 基于 构件 的 开发 方法 中 ， 每 一 个 子 系统 都 被 设计 成 一 个 分 布 式 的 独立 构件 ， 从 而 有 
助 于 实现 分 布 式 的 、 高 度 可 配置 的 和 基于 消息 的 设计 目标 。 一 个 分 布 式 构件 (distributed 
component ) 是 一 个 具有 明确 定义 接口 的 并 发 对 象 ， 也 是 分 布 和 部 署 的 逻辑 单元 。 一 个 良好 设 
计 的 构件 是 能 够 在 不 同 应 用 中 复 用 的 ， 而 非 只 能 在 其 原本 所 属 的 应 用 中 使 用 。 一 个 构件 既 可 
以 是 复合 构件 也 可 以 是 简单 构件 。 复 合 构件 (composite component ) 是 由 其 他 部 分 构件 (part 
component ) 复合 而 成 的 。 简 单 构件 ( simple component ) 内 部 没有 部 分 构件 。 
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服务 可 以 集成 到 基于 构件 的 分 布 式 软件 体系 结构 中 。 服 务 被 设计 为 具有 供给 接口 的 构件 ， 
我 们 可 以 使 用 具有 “服务 发 现 ”( Service Discovery ) 模式 的 构件 来 发 现 它 ， 而 后 使 用 具有 
“代理 者 ”模式 的 构件 (如 “代理 者 句柄 ”模式 ) 与 之 通信 ， 如 第 16 章 所 述 。 

因为 构件 能 够 被 分 配 到 具有 不 同 地理 位 置 的 结 点 上 ， 所 以 必须 限制 构件 间 的 所 有 通信 为 
消息 通信 。 由 此 ， 一 个 结 点 上 的 源 构件 会 通过 网 络 给 另 一 个 结 点 上 的 目的 构件 发 送 消息 。 


17.2 设计 基于 构件 的 分 布 式 软件 体系 结构 


一 个 分 布 式 应 用 包含 了 多 个 可 以 配置 运行 在 分 布 式 物理 结 点 上 的 分 布 式 构件 。 为 了 成 功 
管理 大 规模 分 布 式 应 用 所 固有 的 复杂 性 ， 必 须 提供 一 个 方法 将 应 用 构建 为 多 个 构件 ， 使 得 每 
个 构件 能 在 自己 的 结 点 上 运行 。 当 实现 了 这 样 的 应 用 构建 设计 并 仔细 定义 构件 之 间 的 接口 后 ， 
即 可 独立 设计 每 个 构件 了 。 

为 一 个 分 布 式 应 用 进行 基于 构件 的 软件 体系 结构 设计 主要 包含 3 个 步骤 : 

1) 设计 分 布 式 软件 体系 结构 。 将 分 布 式 应 用 构建 为 多 个 成 分 构件 ( constituent 
component )， 每 个 构件 都 能 在 分 布 式 环境 中 的 单个 结 点 上 运行 。 因 为 构件 部 署 在 不 同 的 结 点 
上 ， 所 以 构件 间 的 所 有 通信 必须 限制 为 消息 通信 。 构 件 间 的 接口 要 进行 定义 。13.8 节 中 所 述 
的 子 系统 组 织 准则 用 于 一 开始 确定 构件 。 此 外 的 构件 组 织 准则 用 来 保证 设计 的 构件 是 能 有 效 
部 署 于 物理 结 点 的 可 配置 构件 ， 如 17.5 节 所 述 。 

2) 设计 成 分 构件 。 根 据 定义 ， 由 于 简单 构件 只 能 运行 在 单个 结 点 上 ， 因 此 可 以 通过 第 
14 章 所 述 的 顺序 性 面向 对 象 软件 体系 结构 的 设计 方法 来 设计 每 个 简单 构件 的 内 部 。 

3 ) 部 署 应 用 。 当 分 布 式 应 用 设计 之 后 ， 其 实例 可 以 被 定义 和 部 署 。 在 这 个 阶段 ， 可 以 定 
义 应 用 的 构件 实例 、 将 它们 互相 连接 ， 并 把 它们 映射 到 包含 分 布 式 物 理 结 点 的 硬件 配置 上 。 


17.3 复合 子 系统 和 构件 


复合 子 系统 是 一 个 符合 地 理 分 布 规则 的 构件 。 作 为 一 个 复合 子 系统 的 部 分 的 对 象 一 定位 
于 同一 位 置 ， 而 在 不 同 地 理 位 置 的 对 象 一 定 不 存在 于 同一 复合 子 系统 中 。 如 第 13 章 所 述 ， 不 
同 复合 子 系统 中 的 对 象 可 以 组 成 一 个 聚合 子 系统 (aggregate subsystem ) 一 一 例如 ， 在 分 层 的 
结构 中 ， 每 一 层 都 被 设计 为 一 个 包含 一 个 或 者 多 个 复合 子 系统 的 聚合 子 系统 。 

复合 子 系统 是 一 个 封装 了 它 所 有 内 部 构件 ( 对 象 ) 的 构件 。 这 个 构件 是 逻辑 上 和 物理 
上 的 容器 ， 但 是 它 没有 增加 更 多 的 功能 。 因 此 ， 一 个 构件 的 功能 完全 由 它 所 包含 的 部 分 构件 
( part component ) 提供 。 图 17-1 描述 了 一 个 包含 内 部 构件 的 复合 构件 ， 其 中 “用 户 接 口 构件 
“操作 员 表 示 ”( Operator Presentation ) 包含 3 个 内 部 简单 构件 ， 即 “操作 员 交 互 ”( Operator 
Interaction )、“ 报 警 窗 口 ”( Alarm Window ) 和 “事件 监控 窗口 ”( Event Monitoring Window )。 
构件 通常 是 并 发 的 ， 所 以 可 以 用 UML 活动 类 表示 法 来 描述 构件 。 

构件 接收 的 消息 会 传递 到 适当 的 内 部 目的 地 构件 ， 从 内 部 构件 传 出 的 消息 也 能 传递 到 适 
当 的 外 部 目的 地 构件 ， 而 消息 传递 机 制 则 依赖 于 实现 。 这 是 一 种 很 多 基于 构件 的 系统 (Bass, 
Clements, and Kazman 2003 ; Magee, Kramer, and Sloman 2006 ; Selic, Gullekson, and 
Ward 1994; Shaw and Garlan 1996; Szyperski 2003 ) 都 使 用 的 整体 / 部 分 关系 (Buschmann et 
al. 1996). Ж 23 章 描 述 了 一 个 使 用 复合 构件 的 软件 体系 结构 的 例子 ， 叫 做 “应 急 监 控 系 统 ”。 
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«user interaction» 
«component» 
OperatorPresentation 


«user interaction» «user interaction» је замени 
AlarmWindow і У 
OperatorInteraction Window 


图 17-1 REE EAS BY Ee 





17.4 使 用 UML 建 模 构件 


本 节 描 述 了 构件 接口 的 设计 ， 这 是 一 个 在 软件 体系 结构 中 非常 重要 的 问题 ,之 前 在 第 12 
章 最 先 介 绍 过 。 文 中 首先 阐述 如 何 明 确定 义 接口 ， 而 后 介绍 供给 和 请 求 接口 、 端 口 〈 以 及 如 
何 从 供给 和 请 求 接口 角度 来 定义 它们 )、 用 于 连接 构件 的 连接 器 ， 以 及 基于 构件 的 软件 体系 结 
构 的 设计 原则 。 

可 以 用 UML 的 结构 类 (structured class) 有 效 建 模 构件 ， 并 将 构件 画 在 复合 结构 图 上 。 
结构 类 提供 了 具有 供给 和 请 求 接口 的 端口 。 结 构 类 之 间 通 过 由 连接 器 连接 的 端口 来 互相 通信 。 
本 节 描 述 了 如 何 使 用 UML 表示 法 来 设计 基于 构件 的 软件 体系 结构 。 


17.4.1 构件 接口 设计 


如 第 12 章 所 述 ， 一 个 接口 定义 了 一 个 类 或 者 构件 的 外 部 可 见 的 操作 ， 同 时 隐藏 了 该 操 
作 的 内 部 结构 (实现 )。 尽 管 有 很 多 构件 只 设计 有 一 个 接口 ， 但 是 一 个 构件 也 可 能 提供 多 个 接 
口 。 如 果 不 同 构件 出 于 不 同 的 用 途 来 使 用 同一 构件 ， 那 么 可 以 在 该 构件 上 为 这 些 构件 设计 各 
自 的 接口 。 

“警报 服务 ”( Alarm Service) 是 一 个 具有 多 接口 构件 的 例子 。 下 面 的 例子 会 使 用 “应 急 
监控 系统 ”的 两 个 接口 。 每 个 接口 包含 一 个 或 者 


тр инт. шы. 


1) НП: IAlarmService 
alarmRequest (in request, out alarmData) 
供给 操作 : alarmSubscribe (in request, in notificationHandle, out ack) 


• alarmRequest ( їп request, out alarmData ) 
е alarmSubscribe (in request, in 
notificationHandle, out ack ) 
2) НП: IAlarmStatus 
供给 操作 : post (in alarm ) 
3) 接口 : IAlarmNotification 
供给 操作 : alarmNotify (іп alarm ) 


可 使 用 静态 建 模 表示 法 来 描述 一 个 构件 的 接 
口 〈( 见 第 12 章 )， 如 图 17-2 Ву, 使 用 了 构造 
型 « 接口 (interface ) 来 描述 上 例 。 图 17-2 构件 接口 示例 
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17.42 ”供给 和 请 求 接口 


要 为 一 个 软件 应 用 提供 基于 构件 的 软件 体系 结构 的 完整 定义 ， 就 有 必要 先 定义 构件 所 提 
供 的 接口 以 及 构件 所 需 的 接口 。 供 给 接口 定义 了 构件 必须 实现 的 操作 。 请 求 接口 定义 了 在 特 
定 环 境 下 其 他 构件 需 为 本 构件 提供 的 操作 。 

一 个 构件 通过 一 个 或 多 个 端口 与 其 他 构件 交互 ， 我 们 用 供给 和 请 求 接口 来 定义 每 个 构件 
端口 。 端 口 的 供给 接口 定义 了 其 他 构件 使 用 本 构件 时 的 要 求 。 端 口 的 请 求 接口 定义 了 本 构件 
使 用 其 他 构件 时 的 要 求 。 一 个 供给 端口 支持 一 个 供给 接口 ， 一 个 请 求 端口 支持 一 个 请 求 接口 。 
一 个 复杂 端口 同时 支持 一 个 供给 接口 和 一 个 请 求 接口 。 一 个 构件 可 以 有 多 个 端口 。 特 别 地 ， 
如 果 一 个 构件 和 多 个 构件 通信 ， 那 么 它 能 够 为 各 个 与 之 通信 的 构件 使 用 不 同 的 端口 。 图 17-3 
给 出 了 一 个 构件 ， 它 具有 包含 供给 和 请 求 接口 的 端口 。 


«input» 
«component» 
MonitoringSensor 
Component 


«user interaction» 


«сотропепі» 
OperatorAlarmPresentation 





ш 
RAlarmService и PAlarm 
Notification 
А О 
1AlarmService 
[Alarm 


Notification 


RAlarm 
Notification 


«service» 
arm 
Service 





Е 17-3 具有 供给 和 请 求 接口 的 构件 端口 示例 


通常 ， 构 件 的 请 求 端口 的 名 称 会 以 字母 “R” 开 头 ， 强 调 该 构件 有 一 个 请 求 端口 。 构 件 
的 供给 端口 的 名 称 会 以 字母 “P” 开 头 ， 强 调 该 构件 有 一 个 供给 端口 。 在 图 17-3 中 ,“ 监 控 
传感器 构件 ”( Monitoring Sensor Component) 有 一 个 请 求 端口 ， 叫 做 RAlarmStatus， 它 支持 
图 17-2 中 定义 的 IAlarmStatus 请 求 接口 。“ 操 作 员 警报 显示 ”( Operator Alarm Presentation ) № 
件 是 一 个 客户 端 构件 ， 它 具有 一 个 含 请 求 接口 的 请 求 端口 (IAlarmService ) 和 含 供给 接口 的 
供给 端口 (IAlarmNotification ) “IRIRI” (Alarm Service) 具有 两 个 名 为 PAlarmStatus 和 
PAlarmService 的 供给 端口 以 及 一 个 名 为 RAlarmNotification 的 请 求 端口 。 而 端口 PAlarmStatus 
提供 了 一 个 接口 IAlarmStatus， 通 过 它 可 发 送 警 报 器 的 状态 信息 。 端 口 PAlarmService 则 提供 了 
一 个 用 于 让 其 他 客户 端 请 求 警报 服务 的 主 接口 ( 供给 接口 IAlarmService )。“ 警 报 服务 ”通过 
RAlarmNotification 端口 发 送 警报 通知 。 


174.3 ”连接 器 和 交互 构件 
连接 器 将 一 个 构件 的 请 求 端口 和 另 一 个 构件 的 供给 端口 连接 起 来 ， 被 连接 的 两 个 端口 必 
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须 相 互 兼容 。 这 意味 着 当 两 个 端口 相连 时 ， 一 个 端口 的 请 求 接口 必须 与 另 一 个 端口 的 供给 接 
口 相 适 配 ; 也 就 是 说 ， 一 个 构件 的 请 求 接口 所 需要 的 操作 必须 和 另 一 个 构件 的 供给 接口 所 提 
供 的 操作 一 致 。 当 一 个 连接 器 连接 了 两 个 复杂 端口 时 (此 时 ， 每 个 端口 都 包含 一 个 请 求 接口 
和 一 个 供给 接口 )， 那 么 前 一 个 端口 的 请 求 接口 需要 与 后 一 个 端口 的 供给 接口 相 适 配 ， 而 后 一 
个 端口 的 请 求 接口 需要 与 前 一 个 端口 的 供给 接口 相 适 配 。 

图 17-4 展示 了 三 个 构件 (“监控 传感器 构件 ”,“ 操 作 员 警报 显示 ”和 “警报 服务 ”) 
是 如 何 交互 的 。 第 一 个 连接 器 是 单 向 的 (如 箭头 方向 所 示 )， 将 “监控 传感器 构件 ”的 
RAlarmStatus 请 求 端口 连接 到 “和 警报 服务 ”的 PAlarmStatus 供给 端口 上 。 图 17-3 表明 这 些 
端口 都 是 适 配 的 ， 因 为 它 可 以 使 IAlarmStatus 请 求 接口 与 IAlarmStatus 供给 接口 相连 接 。 第 
二 个 连接 器 也 是 单 向 的 ， 将 “操作 员 警 报 显 示 ” 的 请 求 端口 RAlarmService 连接 到 “和 警 
报 服务 ”的 供给 端口 PAlarmService 上 。 检 查 图 17-3 中 的 端口 后 可 知 这 些 端口 也 是 适 配 
的 ， 因 为 IAlarmService 请 求 接口 连接 到 了 同名 的 供给 接口 上 。 第 三 个 连接 器 还 是 单 向 的 ， 
将 “警报 服务 ”的 请 求 端 口 RAlarmNotification 连接 到 了 “操作 员 警 报 显 示 ” 的 供给 端口 
PAlarmNotification 上 ， 通 过 该 连接 需 警 报 通知 可 以 经 由 IAlarmNotification 接口 发 送出 来 。 






«user interaction» 
«component» 


«input» 





Notification 


0 [| = 
КИ 
Ѕегуісе 
图 174 ”一 个 软件 体系 结构 中 构件 、 端 口 和 连接 器 示例 


1744 设计 复合 构件 


复合 构件 被 分 解 为 部 分 构件 ， 并 用 UML 结构 类 表示 。 没 有 内 部 构件 的 构件 被 认为 是 简 
单 构件 。 复 合 构件 内 的 部 分 构件 称 为 实例 ， 因 为 一 个 复合 构件 的 某 一 部 分 可 能 会 在 该 复合 构 
件 中 出 现 多 次 。 

图 17-5 给 出 了 一 个 复合 构件 的 例子 ， 即 “显示 ”( Display ) 构件 ， 它 包含 了 两 个 简单 构 
件 : 名 为 “显示 接口 ”(Display Interface) 的 并 发 构件 和 名 为 “显示 提示 ”(Display Prompt ) 
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的 被 动 构件 。“ 显 示 ” 复 合 构件 的 供给 端口 直接 连接 到 内 部 构件 “显示 接口 ”的 供给 端口 上 。 
具有 这 种 连接 功能 的 连接 器 叫做 委托 连接 器 ， 意 味 着 “显示 ”复合 构件 的 外 层 委 托 端 口 将 从 
“显示 生产 者 ”( Display Producer ) 收 到 的 消息 转发 给 “显示 接口 ”的 内 层 端口 。 这 两 个 端口 
同名 ， 都 是 PDisplay， 因 为 它们 提供 相同 的 接口 。 

只 有 分 布 式 构件 才能 被 部 署 在 分 布 式 配置 的 物理 结 点 上 。 被 动 构件 和 直接 调用 被 动 构 件 
操作 的 构件 都 不 能 单独 部 署 ， 只 有 包含 被 动 构件 的 复合 构件 才能 够 被 部 署 。 因 此 ， 在 图 17-5 
中 ， 只 有 复合 构件 “显示 ”能 够 被 部 署 。 根 据 COMET 原则 ， 只 有 可 部 署 的 构件 才 用 构件 构 
造型 标示 。 
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Я 17-5 复合 构件 的 设计 


17.5 ”构件 组 织 准则 


在 设计 分 布 式 应 用 之 前 ,需要 理解 其 可 能 运行 的 分 布 式 环境 。 构 件 组 织 准 则 提供 一 些 指 
导 原 则 来 帮助 开发 出 可 配置 的 分 布 式 应 用 ， 这些 可 配置 的 分 布 式 应 用 可 被 映射 到 分 布 式 环境 
中 的 不 同 地 理 位 置 的 结 点 上 。 而 应 用 到 底 映 射 到 哪个 结 点 上 则 需要 在 之 后 确定 ,届时 需要 初 
始 化 并 部 署 单独 的 目标 系统 。 故 而 设计 可 配置 的 构件 是 很 有 必要 的 ， 因 为 只 有 这 样 才能 有 效 
地 将 其 映射 到 分 布 式 的 物理 结 点 上 。 因 此 ， 构 件 组 织 准则 要 考虑 分 布 式 环境 的 特性 。 

在 分 布 式 环境 中 ， 一 个 构件 也 可 能 和 某 个 特定 的 物理 位 置 相关 或 者 被 限定 运行 在 某 个 硬 
件 资 源 上 。 这 种 情况 下 ， 构 件 就 只 能 执行 在 那个 特定 位 置 的 结 点 或 者 某 个 硬件 上 。 


17.5.1 与 物理 数据 源 的 邻近 性 


在 分 布 式 环境 中 ， 数 据 源 的 物理 位 置 之 间 可 能 相距 其 远 。 我 们 的 设计 需要 让 构件 靠近 它 
的 物理 数据 源 以 保证 能 快速 获取 数据 ， 在 构件 对 数据 获取 速率 要 求 很 高 时 这 一 点 尤为 重要 。 
图 17-6 所 示 的 “应 急 监 控 系 统 ”的 例子 中 ,“ 远 程 系统 代理 ”( Remote System Proxy ) 构件 就 
设计 得 靠近 其 物理 数据 源 。 


17.5.2 局 部 自治 性 
一 个 分 布 式 构件 通常 会 提供 与 某 些 特定 网 址 相关 的 服务 ， 此 时 ， 不 同 的 网 址 会 提供 


Ф 17 # 


МОРЕ ТТН R EHI 233 


相同 的 服务 。 每 个 构件 实例 都 将 部 署 在 一 个 独立 结 点 上 ， 因 此 它 具 备 了 更 多 的 局 部 自治 
性 。 如 果 某 结 点 上 构件 的 行为 与 其 他 结 点 相对 独立 ,那么 当 其 他 结 点 失效 时 ， 它 仍然 可 以 
工作 。 图 17-7 所 示 的 局 部 自治 构件 的 例子 是 “工厂 自动 化 系统 ”中 的 “自动 引导 车 辆 系统 ” 


(Automated Guided Vehicle System ) 构件 。 












«proxy» 
«component» 
RemoteSystem 
Proxy 


PMonitoring 
Status 


REvent PMonitoring 
Notification Service 





«service» 
Monitoring 
DataService 


17-6 邻近 物理 数据 源 的 构件 示例 


“自动 引导 车 辆 系统 ”的 局 部 自治 的 示例 在 图 17-8 中 有 更 详细 的 介绍 。 用 于 控制 的 控制 
构件 是 “车 辆 控制 ”( Vehicle Control )， 它 从 “系统 监督 代理 ”( Supervisory System Proxy ) 接 
收 移动 命令 ， 并 控制 “发 动机 构件 ”( Motor Component ) 沿 着 轨迹 启动 或 停 下 以 及 控制 “机 
械 辟 构件 ”( Arm Component) 加 载 或 印 载 部 件 。 它 同时 也 接收 来 自 于 “到 达 传 感 器 构件 ” 
( Arrival Sensor Component ) 的 消息 ， 此 时 意味 着 有 车 辆 到 站 了 。 


17.5.3 PERE 


如 果 一 个 结 点 内 提供 了 对 时 间 有 高 要 求 
的 功能 ， 那 么 构件 的 性 能 也 会 更 好 并 更 有 预 
测 性 。 在 一 个 给 定 的 分 布 式 应 用 里 ， 一 个 实 
时 构件 可 以 在 一 个 给 定 结 点 上 运行 对 时 间 有 
高 要 求 的 服务 ， 而 在 其 他 结 点 上 运行 对 时 间 
要 求 不 高 甚至 没有 时 间 要 求 的 服务 。 图 17-7 
中 的 “自动 引导 车 辆 系统 ”构件 就 满足 这 个 
标准 。 


17.5.4 ”特定 硬件 
一 个 构件 也 许 需 要 部 署 在 特定 的 结 点 上 ， 
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图 17-7 局 部 自治 的 构件 示例 


这 可 能 是 因为 它 要 支持 像 向 量 处 理 器 那样 具有 特定 目的 的 硬件 ， 也 可 能 是 因为 它 必须 与 连接 


234 Бр ККТ 


在 特定 结 点 上 的 外 围 设备 、 传 感 器 或 执行 器 (actuator) 交互 。“ 监 控 传感器 构件 ”( 17-4) 
的 实例 会 与 特定 目的 的 传感器 交互 。“ 机 械 臂 构件 ”和 “发 动机 构件 ”( 图 17-8) 都 与 特定 目 
的 的 执行 器 交互 。 Sth 










= 
«proxy» «input» 
«component» «component» 
17.5.5 IO 构件 SupervisorySystem ArrivalSensor 
Proxy Com = nent 





VO 构件 可 以 设计 为 具有 相对 较 高 自治 性 ” RAGvct 
并 靠近 物理 数据 源 。 特 别 地 ， 那 些 “ 聪 明 ” 的 
设备 包含 了 与 设备 交互 并 控制 设备 的 软 硬 件 ， 
并 会 被 赋予 更 大 的 局 部 自治 性 。 一 个 IO 构件 
通常 由 多 个 设备 接口 对 象 组 成 ， 但 也 可 能 包含 
用 于 局 部 控制 的 控制 对 象 和 用 于 存储 本 地 数据 
的 实体 对 象 。 

IO 构件 是 对 与 外 部 环境 进行 交互 的 构件 。， ЗЕН 
的 统称 ; 它们 包括 输入 构件 、 输 出 构件 、L/O ут ен one 
构件 (同时 提供 输入 和 输出 ) 网 络 接口 构件 
和 系 统 界面 构 件 Component Component 

在 图 17-8 所 示 的 “自动 引导 车 辆 系统 ”中 ， 图 17-8 ”控制 和 IO 构件 示例 
“到 达 传 感 器 构件 ”( Arrival Sensor Component ) 
是 一 个 输入 构件 的 例子 ， 而 “机 械 辟 构件 ”和 “发 动机 构件 ”都 是 输出 构件 的 例子 。 


PAGVCtrl 


any | RAGVStatus 
«component» 
Vehicle Control 



















17.6 组 消息 通信 模式 


目前 描述 的 消息 通信 模式 涉及 一 个 源 构 件 和 一 个 目的 构件 的 情况 。 有 些 分 布 式 应 用 中 的 通 
信 需 要 具有 和 群 组 通信 的 性 质 。 这 是 一 种 一 对 多 的 消息 通信 机 制 ， 其 中 一 个 发 送 者 将 一 条 消息 发 送 
给 多 个 接收 者 。 分 布 式 应 用 支持 两 类 组 消息 通信 ( 有 时 也 称 为 组 播 通信 ): 广播 通信 和 组 播 通信 。 


17.6.1 广播 消息 通信 模式 


在 广播 (或 者 广播 通信 ) 模式 中 ,一 个 主动 消息 被 发 送 给 所 有 的 接收 者 ， 例 如 通知 它们 
即将 关机 。 每 个 接收 者 都 要 决定 是 处 理 这 个 消息 还 是 丢弃 这 个 消息 。 图 17-9 给 出 了 广播 模式 
的 例子 。“ 和 警报 处 理 服 务 ”( Alarm Handling Service ) 发 送 alarm Broadcast 消息 给 所 有 的 “ 操 
作 员 交互 ”( Operator Interaction ) 构件 实例 。 每 个 接收 者 必须 决定 自身 是 否 采 取 对 应 行动 或 
者 忽略 这 个 消息 。 下 面 对 这 个 交互 模式 进行 更 加 详细 的 描述 : 


B1 :“ 事 件 监控 器 ”(Event Monitor) 发 送 警 报 消息 给 “警报 处 理 服务 ”( Alarm 


Handling Service ) 


B2a，B2b，B2c :“ 警 报 处 理 服 务 ” 向 所 有 的 “操作 员 交 互 ”( Operator Interaction ) 
构件 广播 alarm Broadcast 消息 。 每 个 接收 者 决定 采取 动作 或 者 忽略 这 个 消息 。 





17.6.2 订阅 /通知 消息 通信 模式 
组 播 通信 为 群 组 通信 提供 了 一 种 具有 更 大 选择 性 的 方式 ， 其 中 同一 消息 会 发 送 给 一 个 组 
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的 所 有 成 员 。 订 阅 /通知 模式 使 用 了 组 播 通信 的 方式 ， 订 阅 了 某 个 组 的 构件 会 接收 该 组 发 送 
给 组 内 成 员 的 所 有 消息 。 一 个 构件 能 够 订阅 (请求 加 入 ) 或 者 取消 订阅 (离开 ) 一 个 组 ， 也 
能 同时 成 为 多 个 组 的 成 员 。 发 送 者 〈 也 被 称 作 发 布 者 ) 不 需要 知道 每 个 组 成 员 即 可 向 一 个 组 
发 送 消息 。 然 后 ， 这 个 消息 被 发 送 给 组 里 所 有 的 成 员 。 向 组 内 所 有 的 成 员 发 送 同 一 消息 称 为 
组 播 通 信 。 向 一 个 订阅 者 发 送 的 一 个 消息 被 称 为 一 个 事件 通知 。 在 一 个 订阅 列表 上 ， 一 个 成 
员 可 以 接收 多 个 事件 通知 消息 。 订 阅 /通知 模式 在 因特网 上 非常 流行 。 











«user interaction» 
«component» 
firstOperatorinteraction 





— > 


Вга: alarmBroadcast 


«user interaction» 
«component» 
secondOperatorinteraction 


«user interaction» 
«component» 
thirdOperatorinteraction 


图 17-10 展示 了 一 个 订阅 /通知 模式 的 例子 。 首 先 ， 三 个 “操作 员 交 互 ”( Operator 
Interaction ) 构件 的 实例 向 “警报 处 理 服务 ”( Alarm Handling Service) 发 送 一 个 “订阅 ” 消 
息 ， 旨 在 请 求 得 到 某 种 类 型 的 警报 的 通知 。 每 次 “警报 处 理 服务 ”接收 一 个 新 的 这 种 类 型 
的 “警报 ”"， 它 将 向 订阅 该 广播 的 所 有 的 “操作 员 交 互 ” 构 件 组 播 这 个 “警报 通知 ”( alarm 
Notification ) 消息 。 交 互 模式 的 详细 描述 如 下 : 













=> 
B2b: alarmBroadcast 





«service» 
: AlarmHandlingService 


B1: alarm | 





эш 


B2c: alarmBroadcast 





«input» 
«component» 
: EventMonitor 






图 17-9 广播 模式 示例 


S1，S2，S3:“ 操 作 员 交互 ”构件 订阅 接收 警报 通知 
N1: “事件 监控 器 ”向 “警报 处 理 服 务 ” 发 送 一 个 警报 消息 


N2a，N2b，N2c :“ 警 报 处 理 服务 ”检查 请 求 通知 这 种 类 型 警报 的 订阅 者 名 单 。 然 
后 向 名 单 上 的 “操作 员 交 互 ” 构 件 组 播 这 个 “警报 通知 ”消息 。 每 一 个 接收 者 采取 适当 的 
行为 来 响应 这 个 警报 通知 。 





一 个 订阅 /通知 模式 的 变种 是 每 个 消息 生产 者 只 有 唯一 一 个 订阅 者 的 情况 。 这 适用 于 
点 对 点 的 场景 ， 此 时 ,消息 生产 者 不 知道 谁 是 消费 者 ， 并 且 最 多 有 一 个 消费 者 。 消 费 者 能 
够 订阅 一 个 生产 者 ， 向 它 发 送 一 个 句柄 ， 生 产 者 随后 使 用 这 个 句柄 发 送 消 息 给 消费 者 。 这 
样 有 利于 反 转 依赖 关系 ， 因 为 通过 订阅 的 优势 ， 消 费 者 依赖 于 生产 者 而 不 是 生产 者 依赖 于 
消费 者 。 
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«user interaction» 
«component» 


S1: subscribe firstOperatorinteraction 
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N2a: alarmNotify 









«user interaction» 
«component» 
secondOperatorinteraction 






«service» 


: AlarmHandlingService 
о subscribe 


Nt: alarm | 
~ 


«input» N2c: alarmNoti 
«component» чу «user interaction» 


: EventMonitor «component» 
thirdOperatorinteraction 


$2: subscribe 
я-— 

















一 一 > 
N2b: alarmNotify 














图 17-10 订阅 /通知 模式 示例 


17.6.3 ”使 用 订阅 和 通知 的 并 发 服务 设计 


图 17-11 展示 了 一 个 并 发 服务 设计 的 例子 ， 它 包含 一 个 支持 订阅 /通知 模式 的 新 闻 档 案 
服务 ( 见 17.6.2 节 )。 这 个 并 发 服务 包含 一 个 新 闻 档 案 以 及 多 个 像 “ 新 闻 档 案 服务 ”( News 
Archive Service ) 和 “新 闻 更 新 服务 ”( News Update Service) 等 服务 的 服务 实例 ， 它 为 自己 
的 客户 端 提供 了 订阅 /通知 服务 。“ 订 阅 服务 ”( Subscription Service ) 维护 一 个 订阅 新 闻 的 客 
户 订 阅 单 。 当 一 个 记者 发 布 一 个 新 闻 事件 时 ,“ 新 闻 更 新 服务 ”( News Update Service) 更 新 
新 闻 档 案 并 且 告 知 “ 通 知 服务 ”( Notification Service ) 这 一 情况 。“ 通 知 服务 ”查询 “订阅 单 ” 
(Subscription List ) 来 确认 哪些 客户 已 订阅 过 这 种 新 闻 ， 然 后 向 他 们 通知 该 新 闻 事 件 。 










«service» 
aConcurrentNewsService 











Q1, $1, E1: clientRequest 






Q2: query 


Archive $2: subscribe 





: NewsService 
Coordinator 


04: archive 
Data 





1, E6: event 
Subscribers 


: Notification 
Service 


| E7: eventNotification 





图 17-11 并 发 服务 “订阅 /通知 ”的 示例 
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图 17-11 所 示 的 并 发 通信 图 显示 了 三 个 不 同 的 交互 : 一 个 简单 的 查询 交互 、 一 个 新 闻 事 
件 订阅 交互 和 一 个 新 闻 事 件 通知 交互 。 在 查询 交互 中 (不 涉及 订阅 )， 一 个 客户 向 “新 闻 服 
务 协 调 器 ”( News Service Coordinator) 发 出 请 求 ， 进 而 “新 闻 服 务 协调 器 ”又 向 “新 闻 档 案 
服务 ”( News Archive Service ) 发 送 一 个 新 闻 档 案 查 询 请 求 。 后 者 查询 “新 闻 档 案 ”( News 
Archive ) 并 直接 将 消息 响应 发 送 给 “客户 ”( Client )。 由 于 多 个 服务 可 并 发 访问 新 闻 档 案 和 
订阅 单 ， 所 以 此 时 需要 在 底层 数据 库 或 者 访问 数据 的 服务 上 提供 数据 同步 访问 的 能 力 。 

我 们 给 予 这 三 种 事件 序列 不 同 的 前 级 来 区 分 它们 : 


查询 交互 ( Q Bw ) 
: 一 个 客户 发 送 一 个 查询 给 “新 闻 服 务 协调 器 ”一 一 比如 ， 请 求 最 近 24 小 时 的 新 


: “新闻 服务 协调 器 ”将 查询 转发 给 “新 闻 档 案 服 务 ” 的 实例 。 
:“ 新 闻 档 案 服 务 ” 发 送 合 适 的 档案 数据 一 一 例如 过 去 24 小 时 的 新 闻 事件 一 一 给 客户 。 


事件 订阅 交互 (SHA ) 
S1:“ 新 闻 服 务 协调 器 ”接收 客户 的 订阅 请 求 。 
S2 :“ 新 闻 服 务 协 调 器 ”发 送 一 个 “订阅 ”(subscribe) 消息 给 “订阅 服务 ” 
( Subscription Service )。 


S3:“ 订 阅 服务 ”将 这 个 客户 添加 到 “订阅 单 ”。 


S4 :“ 订 阅 服务 ”向 这 个 客户 发 送 一 个 订阅 “服务 响应 ”( service Response) НА, 
来 确认 这 个 订阅 。 


事件 通知 交互 (Е в) 
E1: 一 个 新 闻 记 者 客户 发 送 一 个 新 闻 更 新 请 求 给 “新 闻 服 务 协调 器 ”。 
E2:“ 新 闻 服 务 协 调 器 ”将 更 新 请 求 转发 给 “新 闻 更 新 服务 ”( News Update Service )。 
E3，E4 :“ 新 闻 更 新 服务 ”更 新 “新 闻 档 案 ” 并 且 向 “通知 服务 ”( Notification 
Service ) 发 送 一 个 “事件 到 达 ”( event Arrival ) 消息 。 313 
E5，E6 :“ 通 知 服务 ”( Notification Service) 查询 “订阅 单 "， 获 得 事件 订阅 者 的 名 
单 ( 即 订阅 了 这 种 类 型 事件 的 客户 )。 
E7:“ 通 知 服务 ”向 所 有 的 订阅 者 组 播 这 个 “事件 通知 ”( event Notification ) 消息 。 
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在 设计 并 实现 了 分 布 式 应 用 之 后 ， 就 能 够 定义 并 部 署 它 的 实例 了 。 一 个 分 布 式 配置 由 多 
个 分 布 于 不 同 地 理 位 置 并 通过 网 络 连接 的 物理 结 点 组 成 ， 在 系统 部 署 时 ， 我 们 定义 分 布 式 应 
用 的 一 个 实例 (或 称 之 为 目标 应 用 )， 并 将 它 映射 为 一 个 分 布 式 配置 。 


17.7.1 应 用 部 署 事务 
在 部 署 应 用 时 ， 应 确定 需要 哪些 构件 实例 。 此 外 ， 也 有 必要 确定 构件 实例 之 间 的 交互 方 
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式 以 及 如 何 将 构件 实例 分 配 到 物理 结 点 上 。 特 别 需 要 完成 以 下 活动 : 

e 确定 构件 实例 。 对 拥有 多 个 实例 的 构件 ， 有 必要 确定 满足 需要 的 构件 实例 。 例 如 ， 
在 一 个 分 布 式 “应 急 监 探 系统” 中， 必须 确定 在 目标 应 用 中 需要 的 构件 实例 的 数 
目 。 同 时 ， 也 必须 为 每 个 传感器 确定 一 个 “监控 传感器 构件 ”( Monitoring Sensor 
Component ) 实例 ， 为 每 个 远程 系统 确定 一 个 “远程 系统 代理 ”( Remote System 
Proxy ) 实例 ， 还 要 为 每 个 操作 人 员 确 定 一 个 “操作 员 交 互 ”( Operator Interaction ) 构 
件 实例 。 每 一 个 构件 实例 必须 有 一 个 唯一 的 名 字 以 使 得 它 能 被 唯一 识别 。 对 于 被 参数 
化 的 构件 ， 需 确定 它 的 每 个 实例 的 参数 ， 比 如 实例 名 称 〈 如 远程 代理 的 ID 或 者 操作 
员 ID )、 传 感 器 名 称 、 传 感 器 限制 和 警报 名 称 。 
连接 构件 实例 。 应 用 的 体系 结构 决定 了 构件 之 间 如 何 通信 。 在 这 个 阶段 将 连接 构件 
实例 。 比 如 ， 在 图 17-12 所 示 的 分 布 式 “应 急 监 控 系 统 ” 中 ,每 一 个 “监控 传感器 构 
件 ” 的 实例 都 会 与 “警报 服务 ”( Alarm Service ) 构件 和 “监控 数据 服务 ”( Monitoring 
Data Service ) 构件 相连 接 。 这 是 因为 ， 当 “警报 服务 ”向 “操作 员 展 现 ”( Operator 
Presentation ) 构件 发 送 一 个 警报 通知 消息 时 必须 能 识别 它 把 消息 发 送 给 哪 一 个 操作 人 
员 了 。 
映射 构件 实例 为 物理 结 点 。 例 如 ， 两 个 构件 能 够 各 自 部 署 在 单独 的 物理 结 点 上 运行 ， 
或 者 它们 也 能 够 部 署 在 同一 个 物理 结 点 上 运行 。 部 署 图 可 以 表示 目标 应 用 的 物理 结 点 


的 分 布 配置 情况 。 
[ 
«user interaction» 
«component» {Layer 3} 
: Operator 
Presentation 
















alarmRequest 
(in request, out alarmData) 
alarmSubscribe (in request, 
in notificationHandle, out ack) 
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«input» «proxy» 
«componenb» «сотропепі» {Layer 2} 
: MonitoringSensor : RemoteSystem 
Component Proxy 
post (event) monitoringRequest event 

(in request, Л Notify 

out monitoringData) ‘event 

os (alarm) post (event) monitoringSubscribe (in request, ( ) 

> in notificationHandle, out ack) 
alarmNotify (alarm) И 
«service» 
=. : Monitoring {Layer 1} 
DataService 


图 17-12 “分布 式 “ 应 急 监控 系统 ”示例 
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17.7.2 ”应 用 部 署 示例 


我 们 将 分 布 式 “应 急 监 控 系 统 ” 来 作为 一 个 应 用 部 署 的 例子 。 图 17-13 中 的 部 署 图 表 
示 了 它 的 应 用 配置 情况 。 为 了 获得 局 部 自治 性 和 足够 的 性 能 ， 每 一 个 “监控 传感器 构件 ” 
( Monitoring Sensor Component ) 的 实例 ( 每 一 个 传感器 有 一 个 实例 ) 都 被 部 署 在 单独 的 结 
点 上 。 这 样 ， 一 个 传感器 结 点 失效 不 会 影响 其 他 结 点 。 每 一 个 “远程 系统 代理 ”( Remote 
System Proxy) 的 实例 ( 每 一 个 远程 系统 有 一 个 实例 ) 都 被 部 署 在 一 个 单独 的 结 点 上 ， 旨 
在 靠近 物理 数据 源 。 损 失 一 个 远程 系统 结 点 意味 着 这 个 远程 系统 不 再 能 够 提供 服务 ， 但 是 
其 他 结 点 不 会 受到 影响 。 出 于 性 能 考虑 ,“ 警 报 服务 ”( Alarm Service) 和 “监控 数据 构件 ” 
( Monitoring Data Service ) 分 别 被 部 署 在 单独 的 结 点 上 以 便 响应 服务 请 求 。 最 后 ,“ 操 作 员 展 
现 ”( Operator Presentation ) 构件 的 每 一 个 实例 都 被 部 署 在 单个 的 操作 员 结 点 上 ， 旨 在 实现 局 






























部 自治 。 
Remote System Monitoring Sensor 
Proxy Component 
{1 node per remote {1 node per 
system} monitoring location} 
rator 
Presentation 
«wide area network» {1 node per 
operator} | 
ЕН Е ЕЯ 
Monitoring Data 
Alarm Service Service 
pee] =] 
图 17-13 ”分布 式 应 用 “应 急 监 控 系统 ”的 部 署 示 例 
17.8 BE 


本 章 描述 了 基于 构件 的 软件 体系 结构 设计 。 针 对 那些 能 部 署 并 运行 在 分 布 式 配 置 的 分 布 
式 平台 上 的 构件 ， 本 章 描述 了 设计 这 类 构件 的 构件 组 织 准则 ， 进 而 讨论 了 如 何 设计 构件 接口 、 
拥有 请 求 接口 和 供给 接口 的 构件 端口 及 连接 适 配 端口 的 连接 器 ， 并 用 UML 2 表示 法 的 复合 结 
构图 来 表示 基于 构件 的 软件 体系 结构 。 此 外 ， 本 章 还 讨论 了 设计 构件 过 程 中 的 考虑 因素 与 利 
WAT. ТЕ 23 章 中 给 出 了 设计 “应 急 监 控 系 统 ” 这 一 基于 构件 的 软件 体系 结构 的 案例 研 
究 。 如 第 22 章 中 “在 线 购物 系统 ”的 案例 研究 所 述 ， 分 布 式 构件 也 可 以 集成 到 面向 服务 的 体 
系 结构 中 。 


练习 


选择 题 ( 每 道 题 选择 一 个 答案 ) 
1. 在 基于 构件 的 分 布 式 软件 体系 结构 中 ， 下 列 有 关 构 件 部 署 的 说 法 哪个 最 全 面 ? 
(а) 构件 实例 能 够 部 署 在 分 布 式 地 理 环境 中 的 不 同 结 点 上 
Cb) 在 设计 前 ， 构 件 实 例 能 够 部 署 在 分 布 式 地 理 环境 中 的 不 同 结 点 上 
(с) 在 实现 前 ， 构 件 实例 能 够 部 署 在 分 布 式 地 理 环境 中 的 不 同 结 点 上 
(4) 在 设计 和 实现 之 后 ， 构 件 实例 能 够 部 署 在 分 布 式 地 理 环境 中 的 不 同 结 点 上 
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2. 一 个 构件 接口 包含 哪些 部 分 ? 
Ca) 构件 外 部 可 见 的 操作 (b) 构件 提供 的 操作 
Co) 构件 需要 的 操作 (4) 构件 支持 的 操作 
3. 一 个 构件 的 供给 接口 包含 什么 ? 
(а) 构件 必须 实现 的 操作 Co) 构件 内 部 的 操作 
(с) 构件 使 用 的 操作 Cd) 构件 的 操作 
4. 一 个 构件 的 请 求 接口 包含 什么 ? 
(а) 构件 必须 实现 的 操作 СЬ) 构件 内 部 的 操作 
(с) 构件 使 用 的 操作 (а) 构件 可 见 的 操作 
5. 连接 器 连接 什么 ? 


(а) 一 个 构件 的 供给 端口 到 另 一 个 构件 的 请 求 端口 
(b) 一 个 构件 的 供给 端口 到 另 一 个 构件 的 供给 端口 
(с) 一 个 构件 的 请 求 端口 到 另 一 个 构件 的 供给 端口 
(а) 一 个 构件 的 请 求 端 口 到 另 一 个 构件 的 请 求 端口 





6. 委托 连接 器 连接 什么 ? 
(а) 外 层 供 给 端口 到 内 层 供给 端口 (ъ) 外 层 供给 端口 到 内 层 请 求 端口 
(с) 外 层 请 求 端口 到 内 层 供给 端口 (а) 外 层 供给 端口 到 内 层 请 求 端 口 
7. 什么 是 广播 消息 通信 ? 


(а) 一 个 发 送 给 若干 接收 者 的 消息 
(b) 一 个 发 送 给 某 个 特定 接收 者 的 消息 
(c) 一 个 发 送 给 所 有 接收 者 的 消息 
(4) 一 个 发 送 给 一 个 组 的 所 有 接收 成 员 的 消息 
. 订阅 /通知 模式 的 通信 特点 是 什么 ? 
(а) 一 个 发 送 给 知 干 接收 者 的 消息 
(b) 一 个 发 送 给 某 个 特定 接收 者 的 消息 
(с) 一 个 发 送 给 所 有 接收 者 的 消息 
(а) 一 个 发 送 给 一 个 组 的 所 有 接收 成 员 的 消息 
9. 在 部 署 应 用 时 ; 
(a) 会 执行 应 用 (b) 会 执行 构件 实例 
(с) 会 把 构件 实例 分 配给 硬件 结 点 (4) 会 实例 化 构件 实例 
10. 在 基于 构件 的 设计 中 ， 局 部 自治 性 的 优势 是 什么 ? 
Ca) 如 果 一 个 构件 失控 了 ， 其 他 构件 可 以 继续 执行 
Cb) 构件 可 以 并 发 执行 
(с) 构件 是 分 布 式 的 
(4) 构件 使 用 消息 进行 通信 


со 


| #18 


Software Modeling & Design: UML, Use Cases, Patterns, & Software Architectures 


设计 并 发 和 实时 软件 体系 结构 





本 章 介绍 并 发 和 实时 软件 体系 结构 设计 。 实 时 软件 体系 结构 是 指 必须 同时 处 理 多 个 输入 
事件 流 的 并 发 式 体 系 结 构 ， 它 们 通常 都 是 状态 相关 的 ， 并 且 具 有 集中 的 或 非 集中 的 控制 方式 。 
因此 ， 在 第 10 章 阐述 的 有 限 状 态 机 、 在 第 11 章 阐述 的 状态 相关 的 交互 建 模 以 及 将 在 本 章 给 
出 的 控制 模式 对 于 实时 软件 体系 结构 的 设计 均 至 关 重 要 。 

18.1 节 描 述 并 发 和 实时 软件 体系 结构 设计 相关 的 概念 、 体 系 结构 和 模式 。18.2 节 描 述 实 
时 系统 的 相关 特性 。18.3 节 给 出 实时 软件 体系 结构 的 控制 模式 。18.4 节 描 述 并 发 任务 的 组 织 
准则 。18.5 节 描 述 IO 任务 的 组 织 准则 。18.6 节 给 出 内 部 任务 的 组 织 准则 。18.7 节 描 述 并 发 
任务 的 体系 结构 的 开发 步骤 。18.8 节 说 明 如 何 使 用 任务 通信 和 同步 来 设计 任务 接口 。18.9 说 
明 如 何 将 任务 接口 和 行为 规约 文档 化 。18.10 节 描 述 在 Java 中 使 用 线程 实现 并 发 任务 。 


18.1 并 发 和 实时 软件 体系 结构 的 概念 、 体 系 结构 及 模式 


设计 并 发 对 象 是 设计 实时 软件 体系 结构 中 的 一 个 重要 活动 ， 在 本 章 中 称 并 发 对 象 为 并 发 
任务 。 在 第 14 章 曾 经 介绍 过 被 动 对 象 的 设计 ， 它 不 包含 控制 线程 。 在 第 4 章 引入 了 并 发 的 概 
念 。 设 计 并 发 和 实时 软件 体系 结构 包括 设计 本 章 所 述 的 并 发 任务 和 设计 第 14 章 所 述 的 用 以 实 
例 化 被 动 对 象 的 信息 隐藏 类 。 实 时 软件 体系 结构 也 可 以 是 分 布 式 的 ， 因 而 可 以 作为 基于 构件 
的 软件 体系 结构 的 一 个 特例 来 考虑 。 在 此 背景 下 一 个 任务 (task ) 就 相当 于 一 个 在 第 17 章 介 
绍 过 的 简单 构件 ( simple component )， 这 两 个 术语 在 本 章 等 价 ， 可 以 互 换 使 用 。 

在 设计 并 发 软件 时 ， 我 们 旨 在 开发 一 个 并 发 软件 体系 结构 。 在 该 体系 结构 中 ， 我 们 把 系 
统 分 解 为 一 系列 并 发 任务 ， 并 且 定 义 了 并 发 任务 之 间 的 交互 和 接口 。 为 了 帮助 设计 人 员 确 定 
系统 中 的 各 个 并 发 任务 ， 我 们 给 出 一 些 并 发 任务 组 织 准则 来 将 系统 中 面向 对 象 的 分 析 模 型 转 
化 为 并 发 软件 体系 结构 。 这 些 准 则 是 一 
系列 包含 并 发 和 实时 软件 系统 专家 知识 
的 启发 式 规则 或 指导 原则 。 也 可 以 把 并 
发 任务 应 用 到 软件 体系 结构 模式 中 ; 因 
此 ， 可 以 将 并 发 任务 应 用 到 分 层 模 式 
(第 12 章 ) 和 客户 端 /服务 模式 (第 15 
章 ) 中 ， 由 此 ， 窜 户 端 与 服务 各 自 都 可 
以 设计 成 并 发 软件 体系 结构 。 此 外 ， 也 
可 把 并 发 任务 应 用 在 18.3 节 所 述 的 各 种 
控制 模式 中 。 





18.2 ”实时 系统 的 特点 


实时 系统 (图 18-1) 是 具有 时间 约 
束 的 并 发 系统 ,广泛 使 用 于 工业 、 商 业 图 18-1 实时 系统 





242 BERD KHER HiT 





以 及 军事 应 用 中 。 术 语 实时 系统 通常 是 指 包括 了 实时 应 用 系统 、 实 时 操作 系统 和 实时 МО 子 
系统 等 的 整个 系统 ， 拥 有 与 各 种 传感器 和 执行 器 相交 互 的 专用 设备 驱动 程序 。 由 于 本 章 着 重 
于 应 用 的 设计 ， 因 而 使 用 术语 实时 应 用 而 非 实 时 系统 。 不 过 ， 本 节 将 会 在 一 个 比较 宽泛 的 实 
时 系统 上 下 文中 讨论 实时 应 用 。 

实时 系统 通常 都 很 复杂 ， 因 为 它 必须 处 理 多 个 相互 独立 的 输入 事件 流 并 产生 多 个 独立 的 输 
出 。 虽 然 这 些 事件 必须 符合 系统 需求 中 给 出 的 时 间 性 约束 ， 但 是 它们 何 时 到 达 经 常 难以 预测 。 
事件 到 达 的 顺序 通常 也 难以 预测 ， 并 且 输入 负载 可 能 会 随 着 时 间 发 生 不 可 预测 的 剧烈 变化 。 

实时 系统 通常 被 分 为 硬 实 时 系统 和 软 实时 系统 两 类 。 硬 实时 系统 具有 必须 满足 的 关键 性 
时 限 以 防止 灾难 性 的 系统 失效 。 在 软 实时 系统 中 也 具有 不 希望 被 违反 的 时 限 要 求 ， 但 是 偶尔 
的 超出 时 限 并 不 会 造成 灾难 性 的 后 果 ， 因 而 是 可 以 容忍 的 。 


18.3 ”实时 软件 体系 结构 中 的 控制 模式 


很 多 实时 系统 都 具有 控制 函数 。 为 此 ， 本 节 给 出 若干 可 以 用 于 控制 函数 的 不 同 控 制 模式 ， 
包括 : 集中 式 控制 模式 、 分 布 式 控制 模式 以 及 层次 化 控制 模式 。 为 了 让 模式 能 够 应 用 于 基于 
构件 的 软件 体系 结构 和 实时 软件 体系 结构 ， 这 些 模式 中 使 用 了 构造 型 componenty。 


18.3.1 集中 式 控 制 体系 结构 模式 


集中 式 控制 体系 结构 中 只 包含 单个 控制 构件 。 从 概念 上 说 控制 构件 要 执行 一 个 状态 图 以 
总 控 全 局 并 管理 整个 系统 的 行为 顺序 。 控 制 构件 从 与 其 交互 的 构件 那里 接收 发 生 的 事件 ， 这 
些 构件 包括 各 种 与 外 部 环境 交互 的 输入 构件 及 用 户 接口 构件 ， 例 如 ， 由 传感器 可 得 知 环境 的 
变化 。 控 制 构件 接收 的 输入 事件 通常 会 引起 其 状态 图 的 状态 迁移 ， 从 而 引发 一 个 或 者 多 个 状 
态 相关 的 动作 。 控 制 构件 通过 这 些 动作 控制 系统 中 的 其 他 构件 ， 比 如 ， 可 由 此 控制 输出 构件 
回 外 部 环境 的 输出 一 一 例如 ， 打 开 或 者 关闭 执行 器 。 实 体 对 象 也 可 用 于 存储 其 他 对 象 所 需 的 
临时 数据 。 

该 控制 模式 的 例子 可 以 参考 “巡航 控制 系统 ”( Gomaa 2000) 和 “微波 炉 控 制 系统 ” 
(Gomaa 2005 )。 图 18-2 给 出 了 微波 炉 控 制 系统 的 集中 式 控 制 体系 结构 模式 ， 其 中 并 发 构件 
用 一 个 通用 的 通信 图 表示 。“ 微 波 炉 控制 ”( Microwave Control) 构件 是 一 个 集中 式 控制 构 
件 ， 该 构件 执行 其 状态 图 以 总 控 全 局 并 管理 微波 炉 的 执行 顺序 。“ 微 波 炉 控 制 ” 构 件 从 三 个 
输入 构件 接收 消息 “ 门 构件 ”( Door Component )、“ 重 量 构件 ”( Weight Component ) 
和 “键盘 构件 ”( Keypad Component )， 而 这 三 个 构件 接收 来 自 外 部 环境 的 输入 。“ 微 波 炉 控 
制 ” 构 件 的 动作 指令 发 送 至 两 个 输出 构件 :“ 加 热 元 件 构件 ”( Heating Element， 用 于 开关 
加 热 元 件 ) 和 “微波 炉 显 示 ”( Microwave Display， 用 于 显示 信息 并 提示 用 户 微波 炉 的 当前 
状态 ) 构件 。 


18.32 分布 式 控制 体系 结构 模式 


分 布 式 控制 模式 中 包括 多 个 控制 构件 。 每 个 控制 构件 通过 在 概念 上 执行 一 个 状态 图 以 控 
制 系统 的 特定 部 分 。 控 制 分 布 于 各 个 控制 构件 之 中 ， 并 不 存在 总 控 全 局 的 单一 构件 。 控 制 构 
件 之 间 通 过 点 对 点 的 通信 实现 重要 事件 的 通知 ， 也 通过 与 集中 式 控 制 模 式 中 类 似 的 方式 与 外 
部 环境 相交 互 ( 见 12.2.6 节 )。 
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«component» 
: MicrowaveControl 
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stopCooking() 







«output» 
«component» 
: MicrowaveDisplay 












«output» 
«component» 
: HeatingElementComponent 


图 18-2 集中 式 控制 体系 结构 模式 示例 


图 18-3 给 出 了 一 个 分 布 式 控制 模式 的 例子 ， 其 中 对 系统 的 控制 分 布 于 多 个 控制 器 构件 之 
上 。 每 个 分 布 式 的 控制 器 执行 一 个 状态 机 ， 并 且 通 过 传感器 构件 接收 来 自 外 部 环境 的 输入 ， 
同时 通过 向 执行 器 构件 输出 命令 来 控制 外 部 环境 。 各 个 分 布 式 控制 器 之 间 通 过 消息 承载 事件 
进行 通信 。 
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图 18-3 ”分布 式 控制 体系 结构 模式 示例 


18.3.3 ”层次 化 控制 体系 结构 模式 


层次 化 控制 模式 〈 也 称 为 多 层 控制 模式 ) 包含 多 个 控制 构件 。 每 个 控制 构件 通过 在 概念 
上 执行 一 个 状态 机 来 控制 系统 的 特定 部 分 。 此 外 ， 存 在 一 个 协调 者 构件 通过 协调 所 有 控制 构 
件 完 成 整个 系统 的 控制 。 协 调 者 构件 提供 高 层 控制 ， 包 括 直接 与 各 个 控制 构件 进行 通信 并 且 
决定 各 个 控制 构件 的 下 一 步 动作 ， 同 时 协调 者 也 从 控制 构件 接收 状态 信息 。 

图 18-4 给 出 了 一 个 层次 化 控制 模式 的 示例 ， 其 中 层次 化 控制 器 向 各 个 分 布 式 控制 器 
发 送 高 层 指令 。 分 布 式 控制 器 与 传感器 和 执行 器 构件 相交 互 从 而 实现 低层 控制 ， 并 在 完成 
高 层 命令 时 向 层次 化 控制 器 发 回响 应 。 各 个 分 布 式 控制 器 也 可 以 向 层次 化 控制 器 发 送 进度 
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Я 18-4 层次 化 控制 体系 结构 模式 示例 


actuator sensor 


a Input 7, 






sensor 
Input 7 
















«output» 
component» 
: ActuatorCmpt 


«output» 
component» 
: ActuatorCmpt 





«input» 
«component» 
: SensorCmpt 











184 并 发 任务 组 织 


并 发 任务 是 一 个 主动 对 象 ， 也 指 一 个 进程 或 者 线程 。 在 本 章 中 ,术语 并 发 任务 用 来 表示 
一 个 具有 单个 控制 线程 的 主动 对 象 。 在 一 些 系统 中 并 发 任务 可 能 被 实现 为 具有 单个 线程 的 进 
fe; 也 有 一 些 系统 将 其 实现 为 一 个 重量 级 进程 中 的 单个 线程 ( 轻 量 级 进程 ( Gomaa 2000 )。 

通过 考察 系统 的 动态 特征 可 以 很 好 地 理解 该 系统 的 并 发 结构 。 在 分 析 模 型 中 ， 系 统 表示 
为 一 组 互相 协作 的 对 象 ， 这 些 对 象 之 间 通 过 消息 机 制 进行 通信 。 在 并 发 任务 组 织 阶段 ， 系 统 
的 并 发 特性 被 形式 化 为 一 系列 并 发 任务 以 及 任务 之 间 的 通信 / 同步 接口 。 

分 析 模 型 确定 哪些 对 象 应 该 被 并 发 执行 而 哪些 需要 顺序 执行 ， 从 而 确定 哪些 对 象 是 主动 
的 而 哪些 对 象 是 被 动 的 。 另 外 ， 在 复合 并 发 任务 中 可 以 包含 被 动 对 象 ， 被 动 对 象 的 操作 在 复 
合 任务 的 控制 线程 中 是 顺序 执行 的 。 

根据 第 8 章 提出 的 方法 ， 构 造型 被 用 来 表示 不 同类 型 的 并 发 任务 。 每 个 并 发 任务 可 以 用 
两 种 构造 型 来 表示 : 第 一 种 确定 对 象 角色 准则 ， 这 在 对 象 组 织 阶 段 完成 ， 如 第 8 章 所 述 ; 第 
二 种 构造 型 用 来 指定 并 发 的 类 型 。 在 并 发 任务 组 织 阶 段 ， 如 果 一 个 对 象 被 确定 为 是 主动 的 ， 
则 需要 进一步 确定 其 并 发 类 型 以 显示 其 特性 。 例 如 ， 如 果 一 个 主动 «1/O» 对 象 是 并 发 的 ， 则 
需要 进一步 确定 其 为 下 述 并 发 特征 构造 型 中 的 一 个 : 事件 驱动 任务 «event driveny 、 周 期 性 任 
务 «periodic»， 或 者 按 需 触发 任务 «demand»。 构 造型 也 用 来 描述 与 并 发 任务 相交 互 的 设备 类 
型 。 因 此 ， 一 个 外 部 输入 设备 «external input device» 会 根据 其 特性 被 进一步 分 类 为 事件 驱动 
的 外 部 输入 设备 «event-driven» 或 者 被 动 外 部 输入 设备 kpassive》。 


18.5 ИО 任务 组 织 准则 


本 节 描 述 各 种 IO 任务 组 织 准 则 。 确 定 VO 任务 特性 的 一 个 重要 因素 是 确定 与 该 任务 相 
交互 的 IO 设备 的 特性 。 


18.5.1 事件 驱动 ИО 任务 


当 系 统 中 存在 由 事件 驱动 ( 也 称 为 中 断 驱 动 ) 的 IO 设备 并 需要 与 之 交互 时 ， 就 需要 事 
件 驱 动 VO 任务 。 由 事件 驱动 的 设备 的 中 断 会 触发 事件 驱动 IO 任务 (在 (Gomaa 2000) 中 
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也 称 为 异步 VO 任务 )。 在 任务 组 织 阶 段 ， 分 析 模 型 中 每 个 与 事件 驱动 的 IO 设备 相交 互 的 1 
о 设备 对 象 被 设计 为 一 个 事件 驱动 VO 任务 。 

事件 驱动 TO 任务 的 执行 速度 受制 于 它 正 在 交互 的 IO 设备 ， 因 此 输入 任务 可 能 会 被 一 
直 挂 起 并 等 待 输入 。 然 而 ， 当 被 某 个 中 断 触 发 后 ， 输 入 任务 通常 必须 在 几 毫 秒 之 内 就 对 随后 
的 中 断 进行 响应 以 避免 输入 数据 的 丢失 。 数 据 被 读 和 之 后 输入 任务 会 处 理 这 些 数据 并 将 其 传 
递 给 后 续 处 理 步 骤 ， 比 如 ， 交 给 其 他 任务 继续 处 理 ， 这 就 使 得 输入 任务 可 以 随即 转 而 对 之 后 
到 来 的 中 断 做 出 迅速 的 响应 。 

另 一 种 事件 驱动 IO 任务 是 事件 驱动 代理 任务 ， 此 类 任务 与 外 部 系统 而 非 IO 设备 相交 
互 。 事 件 驱动 代理 任务 通常 使 用 消息 与 外 部 系统 相交 互 。 

图 18-5a 的 通信 图 给 出 的 分 析 模 型 是 一 个 事件 驱动 TO 任务 的 例子 ， 其 中 的 “ 门 传感器 
接口 ”( Door Sensor Interface ) 输入 对 象 表示 一 个 外 部 输入 设备 ， 该 设备 从 真实 世界 中 的 门 接 
收 门 输入 ， 然 后 将 接收 的 输入 数据 转换 为 内 部 格式 并 向 “微波 炉 控制 ”( Microwave Control ) 
对 象 发 送 门 请 求 。 在 任务 组 织 阶段 ， 门 作为 设计 模型 中 的 一 个 事件 驱动 输入 设备 显示 在 并 
发 通信 图 (И 18-55) 中 ， 该 设备 具有 构造 型 kevent driven» 和 «external input device», “4 
门 被 打开 或 者 关闭 时 产生 相应 中 断 。 同 时 ， 在 设计 模型 中 “ 门 传感器 接口 ”( Door Sensor 
Interface ) 对 象 被 设计 成 具有 相同 名 称 的 事件 驱动 输入 任务 ， 以 构造 型 kevent driven» 和 
«input» 显示 在 并 发 通信 图 中 。 当 该 任务 被 “ 门 中 断 ”( Door Interrupt) 触发 时 会 读 取 “ 门 输 
A” (Door Input )， 将 转换 为 内 部 格式 的 输入 作为 “ 门 请 求 ”( Door Request) 消息 发 送 给 “ 微 
波 炉 控 制 ” 任 务 。 在 设计 模型 中 中 断 表 示 为 一 个 异步 事件 。 

Control 


















1 
1: Door Input | 
— i 














«external input 2: Door Request 


device» 
: DoorSensor 


«input» 
: DoorSensor 
Interface 











硬件 /软件 边界 
a) 分 析 模 型 : 通信 图 


i 
! 

1: doorinterrupt | 
(doorlnput) | 
=> | 



























«event driven» 
«external input 
device» 

: DoorSensor 


«event driven» 
«input» 
: DoorSensorinterface 


2: doorRequest 
一 > 





: Microwave 
Control 







硬件 /软件 边界 
b) 设计 模型 : 并 发 通信 图 


图 18-5 事件 驱动 IO 任务 示例 
Ж: 上 图 中 表示 软 硬 件 边界 的 虚线 仅 用 于 示意 目的 ， 并 非 UML 表示 法 的 一 部 分 。 


18.5.2 周期 性 VO 任务 


与 处 理事 件 驱 动 TO 设备 的 事件 驱动 IO 任务 不 同 ， 周 期 性 IO 任务 要 定期 轮 询 一 个 被 动 
VO 设备 。 这 种 情况 下 ， 任 务 的 触发 是 周期 性 的 而 触发 后 执行 的 功能 则 与 VO 相关 。 周 期 性 1 
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О 任务 会 被 外 部 计时 器 发 送 的 计时 器 事件 触发 ， 触 发 后 执行 ГО 动作 ， 随 后 等 待 下 一 个 计时 
器 事件 的 到 来 。 该 种 任务 的 周期 是 两 次 相继 任务 触发 时 间 的 时 间 差 。 

不 同 于 事件 驱动 IO 设备 在 VO 可 用 时 便 会 产生 中 断 ， 周 期 性 IO 任务 通常 用 于 简单 ИО 
设备 。 因 而 ， 周 期 性 IO 任务 经 常用 于 需要 周期 性 采样 的 被 动 传感器 设备 。 周 期 性 VO 任务 的 
概念 被 用 在 很 多 基于 传感器 的 工业 系统 中 ， 这 些 系统 中 经 常 存在 大 量 的 数字 或 模拟 的 传感器 
元 件 ， 其 中 周期 性 VO 任务 会 被 定期 触发 ， 然 后 扫描 这 些 传感器 并 读 取 它 们 的 值 。 

例如 ， 考 虑 一 个 由 周期 性 VO 任务 处 理 的 被 动 数字 输入 设备 一 一 引擎 传感器 。 系 统 中 的 
IO 任务 会 被 计时 器 事件 触发 然后 读 取 设备 状态 信息 。 如 果 数 字 传 感 器 的 值 在 上 次 采样 后 被 改 
变 了 ， 则 任务 状态 也 会 相应 改变 。 在 模拟 传感器 情形 下 一 一 例如 一 个 温度 传感器 一 一 该 传 感 
器 的 当前 状态 值 会 被 周期 性 地 读 取 。 

考虑 图 18-6a 中 的 “温度 传感器 接口 ”( Temperature Sensor Interface ) 对 象 作 为 一 个 周期 
性 IO 任务 的 例子 。 在 分 析 模 型 中 ， 该 对 象 以 «їпрш» 构造 型 表示 在 通信 图 中 ， 并 且 从 一 个 表 
示 为 构造 型 kexternal input device» 的 “温度 传感器 ”( Temperature Sensor ) 中 接收 温度 输入 。 由 
于 “温度 传感器 ”是 一 个 被 动 设备 ， 因 此 在 并 发 通信 图 中 表示 为 构造 型 passivey 和 «external 
input device» ( 见 图 18-6b )。 由 于 被 动 设备 不 产生 中 断 ， 因 而 不 能 使 用 事件 驱动 输入 任务 而 是 
应 该 使 用 一 个 周期 性 输入 任务 来 处 理 ， 即 图 中 所 示 的 “温度 传感器 接口 ”( Temperature Sensor 
Interface ) 任务 ， 该 任务 会 被 一 个 外 部 计时 器 周期 性 地 触发 并 对 温度 传感器 的 值 采样 。 因 此 , 在 
并 发 通信 图 中 ,“ 温 度 传感器 接口 ”对 象 被 设计 为 “温度 传感器 接口 ”periodicy 和 «input» 4E 
务 。 为 了 周期 性 地 触发 “温度 传感器 接口 ”任务 ， 需 要 添加 一 个 «external timem 对 象 ， 即 “ 数 
字 时 钟 ”( Digital Clock )， 如 图 18-6b 所 示 。 被 触发 后 “温度 传感器 接口 ”任务 会 对 温度 传感器 
采样 ， 使 用 当前 温度 值 更 新 “温度 数据 ”( Temperature Data) 实体 对 象 ， 然 后 等 待 下 一 个 计时 
器 事件 。 在 设计 模型 中 计时 器 事件 被 表示 为 一 个 异步 事件 。 
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18.5.3 EID /О 任务 


按 需 驱动 VO 任务 (在 Gomaa [ 2000 ] 中 称 被 动 VO 任务 ) 用 于 处 理 被 动 TO 设备 ， 此 
类 设备 不 需要 轮 询 因 而 无 需 周期 性 IO 任务。 尤其 是 当 计 算 与 IO 要 同时 进行 的 时 候 ， 就 需要 
考虑 使 用 按 需 驱动 ГО 任务 。 一 个 按 需 驱动 IO 任务 用 于 在 下 述 情况 下 与 被 动 IO 设备 交互 : 
ө 对 于 输入 ， 需 要 同时 进行 接收 被 动 设 备 的 输入 与 接收 和 消费 数据 的 计算 性 任务 。 这 
通过 使 用 按 需 驱动 输入 任务 实现 。 在 被 请 求 时 ， 按 需 驱 动 任务 才 会 从 输入 设备 读 取 
数据 。 
o 对 于 输出 ， 需 要 同时 进行 对 设备 的 输出 与 产生 数据 的 计算 性 任务 。 这 通过 使 用 按 需 输 
出 任务 实现 。 在 收 到 输出 请 求 时 ， 按 需 驱 动 输出 任务 通常 用 消息 传递 的 方式 向 设备 输 
出 数据 。 
相对 于 处 理 输入 设备 ， 按 需 驱动 IO 任务 更 常用 于 处 理 输出 设备 ， 这 是 因为 输出 本 身 与 
产生 输出 的 计算 在 更 多 情况 下 可 以 同时 进行 ， 如 下 文 的 例子 所 述 。 通 常 ， 如 果 针 对 被 动 输入 
设备 的 IO 和 计算 同时 进行 ， 会 使 用 周期 性 输入 任务 。 
考虑 一 个 按 需 驱动 的 输出 任务 ， 该 任务 从 生产 者 任务 接收 消息 。 按 需 驱 动 任务 用 构 
HA «demand» 表示 。 同 时 进行 的 计算 与 输出 则 通过 以 下 方式 实现 : 消费 者 任务 将 包含 
在 消息 中 的 数据 向 被 动 输出 设备 ( 即 显示 器 ) 输出 数据 ; 同时 生产 者 任务 准备 下 一 个 消 
息 。 这 一 例子 在 图 18-7 中 给 出 。 其 中 “传感器 数据 显示 接口 ”( Sensor Statistics Display 
Interface ) 是 一 个 按 需 驱动 输出 任务 ， 该 任务 从 “传感器 数据 算法 ”( Sensor Statistics 
Algorithm ) 任务 接收 消息 并 且 显 示 数 据 ， 同 时 ,“ 传 感 器 数据 算法 ”任务 会 计算 接 下 来 
要 显示 的 一 系列 数据 。 由 此 ， 同 时 进行 了 计算 与 输出 。 “传感器 数据 显示 接口 ”任务 在 并 
发 通信 图 中 用 构造 型 x<demand»«output» 任务 表示 。 
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18.6 ”内 部 任务 组 织 准则 


VO 任务 组 织 准 则 用 于 确定 VO 任务 ， 而 内 部 任务 组 织 准则 用 于 确定 内 部 ( 即 非 VO) 任务 。 
18.6.1 周期 性 任务 


很 多 实时 和 并 发 系统 具有 需要 周期 性 执行 的 活动 一 一 例如 ， 需 要 计算 汽车 当前 里 程 或 当 
前 车 速 。 这 些 周期 性 活动 通常 用 周期 性 任务 来 处 理 。 周 期 性 IO 活动 被 构造 成 周期 性 IO ЈЕ 
务 ， 而 周期 性 内 部 活动 则 被 构造 成 周期 性 任务 。 内 部 周期 性 任务 包括 周期 性 算法 任务 。 

一 个 需要 被 周期 性 地 ( 即 定 期 地 、 等 时 间 间 隔 地 ) 执行 的 活动 需要 被 构造 为 独立 的 周期 
性 任务 。 该 任务 会 被 计时 器 事件 触发 并 执行 周期 性 活动 ， 随 后 等 待 下 一 个 计时 器 事件 。 任 务 
的 执行 周期 即 是 两 个 相继 事件 触发 之 间 的 时 间 间 隔 。 

考虑 将 图 18-8a 中 的 “微波 炉 计 时 器 ”( Microwave Timer) 对 象 作 为 一 个 例子 。“ 微 波 
炉 计 时 器 ”对 象 每 隔 一 秒 会 被 触发 一 次 ， 触 发 后 该 对 象 请 求 “ 烤 炉 数据 ”(Oven Data) 对 象 
来 将 豪 饪 时 间 减 少 一 秒 ， 随 后 返回 剩余 的 豪 饪 时 间 。 如 果 亮 饪 结束 ,“ 微 波 炉 计 时 器 ”对 象 
就 会 发 送 一 个 “到 时 ”( Timer Expired) 消息 给 “微波 炉 控 制 ”( Microwave Control ) 对 象 。 
“微波 炉 计时 器 ”对 象 被 设计 为 一 个 周期 性 任务 (图 18-8b )， 当 该 任务 被 周期 性 触发 时 ， 即 
请 求 “ 烤 炉 数 据 ” 对 象 减少 豪 饪 时间 。“ 微 波 炉 计时 器 ”任务 在 并 发 通信 图 中 表示 为 构造 型 
«periodic» 任务 ,“ 烤 炉 数据 ”对 象 是 一 个 被 动 对 象 ， 计 时 器 事件 则 表示 为 异步 事件 。 
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图 18-8 周期 性 任务 示例 
18.6.2” 按 需 驱 动 任务 


许多 实时 和 并 发 系统 中 具有 需要 按 需 执 行 的 活动 ， 这 些 活 动 通常 用 按 需 驱动 任务 来 处 理 。 
事件 驱动 TO 任务 会 被 到 达 的 外 部 中 断 所 触发 ， 而 按 需 驱动 的 内 部 任务 ( 也 称 为 非 周期 性 任 
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务 ) 则 被 到 达 的 外 部 消息 或 事件 所 触发 。 

一 个 被 按 需 触 发 ( 即 当 接收 到 来 自 于 不 同 任务 的 内 部 消息 或 事件 时 触发 ) 的 对 象 被 构造 
成 一 个 独立 的 按 需 驱动 任务 。 当 所 请 求 任务 的 消息 或 事件 按 需 触发 了 该 种 任务 后 ， 这 种 任务 
便 会 开始 处 理 所 需 请 求 ， 随 后 等 待 下 一 个 消息 或 者 事件 。 内 部 按 需 驱动 任务 包括 按 需 驱动 算 
法 和 任务 。 按 需 驱 动 任务 用 构造 型 «demand» 表示 。 

图 18-9 给 出 了 一 个 按 需 驱动 任务 的 例子 。 在 分 析 模 型 中 ,来 自 于 “油泵 控制 ”( Pump 
Control) JZ “RMA” (Pump Command ) 消息 按 需 触发 了 “加 油 算 法 ”(Gas Flow 
Algorithm ) 对 象 ， 随 后 系统 执行 该 算法 ， 即 读 取 当 前 加 油 量 以 及 价格 ,并 计算 总 的 加 油 量 和 
总 价格 ， 而 后 将 这 些 信息 发 送 至 “油泵 显示 接口 ”( Pump Display Interface ) 对 象 (图 18-9a )。 
在 设计 模型 中 ， 把 “加 油 算 法 ”对 象 以 相同 名 称 构造 为 按 需 驱动 算法 任务 ， 当 “ 泵 油 命令 ” 
消息 到 达 时 触发 它 。“ 加 油 算法 ”任务 在 并 发 通信 图 中 用 构造 型 x<demand»«algorithm» 表示 
(图 18-9b )。 其 中 “油泵 控制 ”和 “油泵 显示 接口 ”对 象 也 被 构造 为 任务 ， 而 “ 油 量 ”( Gas 
Flow) 及 “油价 ”( Саз Price ) 实体 对 象 是 被 动 对 象 。 
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a) 分 析 模 型 : 通信 图 
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«output» 
: PumpDisplay 


4: display(gallons, price) Interface 






b) 设计 模型 : 并 发 通信 图 
图 18-9 按 需 驱动 任务 示例 


18.6.3 ”控制 任务 


在 分 析 模 型 中 ， 状 态 相 关 的 控制 对 象 会 执行 一 个 状态 图 。 对 于 具有 约束 形式 的 状态 图 ， 
并 发 不 允许 在 控制 对 象 中 出 现 ， 其 状态 图 的 执行 是 严格 地 顺序 执行 的 。 同 时 ， 一 个 同样 严格 
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顺序 执行 的 任务 可 以 完成 控制 活动 。 执 行 顺序 状态 图 (通常 实现 为 一 个 状态 迁移 表 ) 的 任务 
表示 为 一 个 状态 相关 的 控制 任务 。 控 制 任 务 通 常 是 按 需 驱动 任务 ,需要 由 其 他 任务 发 送 的 消 
息 所 触发 。 状 态 相 关 的 控制 任务 用 构造 型 «state-dependent control» 来 表示 。 

图 18-10 给 出 了 控制 任务 的 例子 。 其 中 状态 相关 的 控制 对 象 “微波 炉 控 制 ”( Microwave 
Control ) ( 图 18-10a ) 执行 “微波 炉 控制 ”状态 图 ， 由 于 状态 图 的 执行 是 严格 顺序 的 ， 该 对 
象 被 构造 为 “微波 炉 控 制 ” 任 务 。 在 并 发 通信 图 中 该 任务 被 表示 为 构造 型 «demand»«state- 


dependent control», 
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a) 分 析 模 型 : 通信 图 
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b) 设计 模型 : 并 发 通信 图 
图 18-10 ”控制 任务 示例 


有 可 能 存在 许多 具有 相同 类 型 的 对 象 。 每 个 对 象 被 设计 成 一 个 任务 ， 其 中 所 有 的 任务 都 
是 同一 个 任务 类 型 的 实例 。 对 于 状态 相关 的 控制 对 象 ， 每 个 对 象 执行 相同 顺序 状态 图 的 一 个 
实例 ， 然 而 ， 这 些 对 象 可 能 处 于 不 同 的 状态 。 这 通过 为 每 个 控制 对 象 提供 一 个 状态 相关 的 控 
制 任务 来 实现 ， 其 中 每 个 任务 都 执行 一 个 状态 图 。 

图 18-11 给 出 了 一 个 关于 同一 类 型 的 多 控制 任务 的 例子 : 一 个 电梯 控制 系统 。 我 们 将 现 
实 世 界 的 电梯 控制 部 分 建 模 为 状态 相关 的 控制 对 象 :“ 电 梯 控 制 ”( Elevator Control )， 并 且 定 
义 一 个 顺序 状态 图 。 在 任务 构造 时 ,“ 电 梯 控 制 ” 对 象 被 设计 为 一 个 状态 相关 的 “电梯 控制 ” 
任务 。 在 具有 多 个 电梯 的 系统 中 ， 每 个 电梯 任务 都 对 应 于 一 个 “电梯 控制 ”对 象 。 这 些 任 务 
是 相同 的 ， 并 且 每 个 任务 执行 相同 状态 图 的 一 个 实例 。 但 是 每 个 电梯 都 可 能 处 于 状态 图 中 的 
不 同 状 态 。 在 图 18- Па 和 18-11b 中 ,“ 电 梯 控 制 ” 对 象 和 “电梯 控制 ”任务 的 多 个 实例 用 
UML 的 多 实例 表示 法 表示 。 


П 
«demand» 
«state dependent «state dependent 
control» control» 
: Elevator : Elevator 
Control Control 








а) 分 析 模型 : 控制 对 象 〈 多 实例 ) b) 设计 模型 : 每 个 电梯 一 个 任务 
图 18-11 同类 型 多 控制 任务 示例 


除了 状态 相关 的 控制 对 象 ， 分 析 模 型 中 的 协调 者 对 象 设计 为 协调 者 任务 (Coordinator 
Task )。 在 此 情况 下 协调 者 任务 的 作用 是 控制 其 他 任务 ,虽然 它 本 身 不 是 状态 相关 的 。 


18.6.4 ”用户 交互 任务 
用 户 通常 会 执行 一 系列 顺序 动作 。 由 于 用 户 与 系统 的 交互 式 顺序 活动 ， 因 而 可 以 用 用 户 
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交互 任务 处 理 。 这 一 任务 的 处 理 速度 经 常 受 制 于 与 用 户 交 互 的 速度 。 顾 名 思 义 ， 用 户 交 互 对 
象 在 分 析 模 型 中 会 被 设计 成 用 户 交互 任务 。 用 户 交 互 任务 通常 是 事件 驱动 的 ， 因 为 来 自 外 部 
用 户 的 输入 会 触发 它们 。 

一 个 用 户 交互 任务 通常 与 多 个 标准 IO 设备 相连 接 ， 例 如 键盘 、 显 示 器 和 上 鼠标， 这些 外 
设 由 操作 系统 控制 。 由 于 操作 系统 为 这 些 设备 提供 了 标准 接口 ， 因 而 无 需 开 发 专用 的 ИО 4E 
务 去 处 理 它们 。 

在 很 多 多 用 户 操作 系统 中 ， 一 个 非常 典型 的 设计 概念 是 让 每 个 用 户 执行 一 个 任务 (one 
task per user )。 例 如 ，UNIX 系统 中 就 是 让 每 个 用 户 执行 一 个 任务 ( 进程 )。 另 外 ， 如 果 用 户 
需要 并 发 执行 多 个 活动 ， 则 为 每 个 顺序 活动 配置 一 个 用 户 交 互 任务 。 因 此 在 UNIX 操作 系统 
中 ， 用 户 可 以 创建 后 台 任务 。 由 此 ， 同 一 用 户 的 所 有 用 户 交互 任务 都 并 发 执行 。 

每 个 顺序 活动 执行 一 个 任务 (one task per sequential activity ) 的 概念 也 用 于 具有 多 
窗口 的 现代 工作 站 系统 中 。 每 个 窗口 执行 单个 顺序 活动 ， 因 而 每 个 窗口 均 对 应 于 一 个 任 
务 。 在 Windows 操作 系统 中 ， 用 户 可 以 在 一 个 窗口 中 运行 Мога 同时 在 另 一 个 窗口 中 运行 
PowerPoint。 其 中 每 个 窗口 对 应 于 一 个 用 户 交互 任务 ， 并 且 每 个 任务 都 可 以 创建 其 他 任务 
(例如 : 在 文档 编辑 的 同时 进行 打印 操作 )。 

图 18-12 给 出 了 一 个 用 户 交 互 任务 的 例子 。“ 操 作 员 交 互 ”( Operator Interaction ) 对 象 接 
受 操 作 人 员 的 命令 ， 而 后 读 取 “传感器 数据 存储 库 ”( Sensor Data Repository ) 实体 对 象 并 将 
数据 显示 给 操作 人 员 ( 图 18-12a )。 用 于 此 例 中 的 所 有 操作 员 交 互 都 是 顺序 的 ， 故 把 “操作 员 
交互 ”对 象 构造 成 用 户 交 互 任务 ( 图 18-12b )。 在 并 发 通信 图 中 显示 这 一 任务 ， 它 具有 构造 型 
«event driven», «user interaction» 任务 。 用 户 输入 会 触发 该 任务 。 
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b) 设计 模型 : 一 个 任务 的 并 发 通信 图 
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с) 设计 模型 : 两 个 任务 的 并 发 通信 图 
图 18-12 用户 交互 任务 示例 
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在 多 窗口 工作 站 环境 中 ， 一 个 工厂 操作 人 员 可 以 在 一 个 窗口 中 看 到 工厂 状态 〈 由 一 个 
用 户 交 互 任 务 支 持 ) 并 且 在 另外 一 个 窗口 中 确认 警报 信息 〈 由 另 一 个 不 同 的 用 户 交 互 任务 支 
持 )。 图 18-12c 给 出 了 这 一 例子 ， 其 中 包括 两 个 用 户 交 互 任务 ， 即 “工厂 状态 窗口 ”( Factory 
Status Window ) 和 “工厂 警报 窗口 ”( Factory Alarm Window )， 这 两 个 任务 并 发 活动 。“ 工 厂 
状态 窗口 ”任务 与 被 动 的 “工厂 状态 存储 库 ”( Factory Status Repository ) 数据 对 象 交 互 ， 同 
时 “工厂 警报 窗口 ”任务 与 被 动 的 “工厂 警报 存储 库 ”( Factory Alarm Repository ) 数据 对 象 
交互 。 


18.7 开发 并 发 任务 体系 结构 


可 以 按 以 下 顺序 把 任务 组 织 准则 应 用 在 分 析 模 型 中 。 在 每 种 情况 下 ， 必 须 首先 确定 分 析 
模型 对 象 在 设计 模型 中 要 被 设计 为 主动 对 象 ( 即 任务 ) 还 是 被 动 对 象 。 同 一 类 型 可 以 有 多 个 
不 同 的 任务 。 

1) ПО 任务 。 始 于 与 外 部 世界 交互 的 设备 IO 对 象 。 确 定 该 对 象 是 被 构造 成 为 事件 驱动 
VO 任务 还 是 周期 性 VO 任务 ， 或 者 被 构造 成 按 需 驱动 IO 任务 。 

2) 控制 任务 。 分 析 每 一 个 状态 相关 的 控制 对 象 和 协调 者 对 象 。 将 其 构造 为 状态 相关 的 控 
制 或 协调 者 任务 (通常 为 按 需 驱动 )。 

3 ) 周期 性 任务 。 分 析 内 部 周期 性 活动 并 将 其 构造 为 周期 性 任务 。 

4) 其 他 内 部 任务 。 对 于 每 个 由 内 部 事件 触发 的 内 部 任务 ,构造 其 为 按 需 驱动 任务 。 

Ж 18-1 简要 给 出 了 将 分 析 模 型 对 象 映射 为 设计 模型 任务 的 指导 方法 。 


ж 18-1 ”从 分 析 模型 对 象 到 设计 模型 任务 的 映射 


分 析 模 型 ( 对 象 ) 设计 模型 ( 任务 ) 
用 户 交 互 事件 驱动 用 户 交互 
输入 /输出 (输入 ， 输 出 ，LO ) 事件 驱动 VO ( 输入 ， 输 出 ，LO ) 


周期 性 VO (输入 ， 输 出 ，LO ) 
按 需 驱动 VO (通常 为 输出 ) 


代理 事件 驱动 代理 
计时 器 周期 性 计时 器 
状态 相关 的 控制 按 需 驱动 的 状态 相关 控制 
协调 者 按 需 驱动 的 协调 者 
算法 按 需 驱动 算法 
周期 性 算法 
初始 化 并 发 通信 图 


在 将 系统 构造 为 各 种 并 发 任务 后 ， 要 画 出 一 个 包含 所 有 任务 的 初始 化 并 发 通信 图 。 在 初 
始 化 并 发 通信 图 中 ,任务 之 间 的 接口 依然 是 分 析 模 型 通信 图 中 的 简单 消息 。 图 18-13 给 出 了 
一 个 初始 化 并 发 通信 图 的 例子 ， 该 图 描述 的 是 一 个 “银行 系统 ”的 “ATM 客户 端 ” 子 系统 。 
第 21 章 将 详细 讨论 该 “ATM 客户 端 ”的 设计 。 下 面 我 们 讨论 任务 接口 的 设计 。 
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18.8 任务 通信 和 同步 


在 将 系统 构造 为 并 发 任务 后 ， 下 一 步 需 要 设计 任务 接口 。 在 此 阶段 ， 任 务 之 间 的 接口 依 
然 是 分 析 模 型 通信 图 中 的 简单 消息 。 因 而 需要 将 这 些 接口 映射 为 消息 通信 、 事 件 同步 或 是 对 
信息 隐藏 对 象 的 访问 。 

在 第 2 章 曾 经 给 出 了 用 来 表示 消息 通信 的 UML 表示 法 。 在 第 12 章 和 第 15 В Г 
发 构件 的 消息 通信 模式 。 在 为 分 析 模 型 开发 的 消息 通信 图 以 及 为 设计 模型 开发 的 初步 并 发 通 
信 图 中 ， 所 有 的 通信 都 用 简单 消息 表示 。 在 设计 建 模 的 这 一 阶段 ， 任 务 接口 在 修改 过 的 并 发 
通信 图 中 定义 和 表示 。 

任务 之 间 的 消息 接口 可 以 是 异步 的 〈 松 耦合 ) 或 同步 的 ( 紧 耦 合 )， 这 已 经 在 第 4 章 给 出 
介绍 并 在 第 12 章 讨论 了 更 多 细节 。 同 步 消 息 通信 有 两 种 : 带 回 复 的 同步 消息 通信 和 不 带 回 复 
的 同步 消息 通信 。 


18.8.1 异步 (мв) 消息 通信 


并 发 任务 之 间 的 异步 消息 通信 也 称 为 松 耦 合 消息 通信 ， 它 是 基于 在 12.3.3 HAMAS 
步 通 信 模 式 的 。 当 消息 生产 者 给 消费 者 发 送 完 一 个 消息 之 后 ， 不 用 等 竺 回复 便 可 继续 发 送 下 
一 个 消息 。 

考虑 图 18-14 给 出 的 并 发 通信 图 ， 其 中 ,“ 门 传感器 接口 ”( Door Sensor Interface ) 任务 
发 送 一 个 消息 给 “微波 炉 控 制 ”( Microwave Control ) 任务 ， 此 处 接口 应 该 设计 为 使 用 异步 消 
息 通信 的 消息 接口 。“ 门 传感器 接口 ”任务 发 送 消息 后 并 不 等 竺 “微波炉 控制 ”任务 接收 消 
息 ， 这 使 得 “ 门 传感器 接口 ”任务 可 以 快速 处 理 新 到 来 的 外 部 输入 。 异 步 消 息 通 信也 为 “ 微 
波 炉 控制 ”任务 提供 了 极 大 的 灵活 性 ， 因 为 它 可 以 通过 一 个 消息 队列 接收 来 自 于 多 个 源 的 消 
息 ， 然 后 处 理 队 列 中 的 第 一 个 消息 而 不 用 关心 消息 源 自 何方 。 


18.8.2” 带 回复 的 同步 (же) 消息 通信 


并 发 任务 之 间 的 带 回复 的 同步 消息 通信 ， 也 称 为 带 回 复 的 紧 耦 合 消 息 通信 ， 是 基于 
12.3.4 节 介 绍 过 的 带 回复 的 同步 消息 通信 模式 。 其 中 ， 消 息 生 产 者 给 消费 者 发 送 完 一 个 消息 
后 会 等 待 它 的 回复 。 

带 回复 的 同步 消息 通信 虽然 用 于 客户 端 / 服 务 器 系统 中 (第 15 章 )， 但 也 可 用 于 单个 消息 
生产 者 向 单个 消息 消费 者 发 送 消息 并 等 待 回 复 的 场景 中 ， 此 时 在 生产 者 和 消费 者 之 间 没 有 消 
息 队 列 。 例 如 在 自动 引导 车 辆 系统 中 ,生产 者 任务 ( 即 车 辆 控制 ( Vehicle Control ) ) 向 消费 者 
任务 ( 即 发 动机 接口 (Motor Interface )) 发 送 开 始 和 停止 消息 ， 随 后 等 待 回复 ， 如 图 18-15 中 
的 并 发 通信 图 所 示 。 生 产 者 由 于 发 送 消息 并 等 待 回复 ， 因 而 与 消费 者 紧 耦 合 。 接 收 到 消息 以 
后 ， 消 费 者 会 处 理 消息 ， 生 成 回复 并 且 将 回复 发 送 给 生产 者 。 在 图 18-15 所 示 的 并 发 通信 图 
中 ， 带 回复 的 同步 消息 通信 的 标记 显示 了 生产 者 发 送 给 消费 者 的 同步 消息 ， 其 中 虚线 表示 对 
生产 者 的 响应 ， 响 应 消息 从 消费 者 返回 给 生产 者 。 
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K 18-14 异步 消息 通信 示例 图 18-15 带 回复 的 同步 消息 通信 示例 
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18.8.3 ЖЕНЕ (ЖЕ) 消息 通信 


并 发 任务 之 间 的 不 带 回复 的 同步 消息 通信 也 称 为 不 带 回 复 的 紧 耦 合 消息 通信 ， 是 基于 不 
带 回复 的 同步 消息 通信 模式 。 消 息 生产 者 向 消息 消费 者 发 送 消息 ， 并 等 待 消 息 被 消费 者 接收 。 
当 消 息 到 达 时 ， 消 费 者 接收 消息 并 释放 生产 者 ， 随 后 生产 者 和 消费 者 一 起 继续 执行 消息 收发 
过 程 。 如 果 没 有 消息 到 来 ， 消 费 者 会 挂 起 。 

图 18-16 给 出 了 一 个 不 带 回复 的 同步 
消息 通信 的 例子 。 其 中 “传感器 数据 显示 
接口 ”( Sensor Statistics Display Interface ) 
是 一 个 按 需 输出 任务 ， 此 任务 从 “传感器 
数据 算法 ”(Sensor Statistics Algorithm ) 
任务 接收 消息 并 显示 ， 如 并 发 通信 图 中 所 
示 (И 18-16). 在 显示 传感器 数据 结果 的 
同时 ,“ 传 感 絮 数据 算法 ”任务 会 计算 下 一 个 要 显示 的 一 系列 数据 值 ， 因 此 输出 和 计算 是 同 
时 进行 的 。 

生产 者 任务 〔( 即 “传感器 数据 算法 ”任务 ) 向 消费 者 任务 ( 即 “ 传 感 器 数据 显示 接口 ”) 
发 送 温度 和 压力 信息 ， 后 者 会 将 信息 显示 出 来 。 在 此 例 中 ， 之 所 以 使 用 不 带 回复 的 同步 消息 
通信 ， 是 因为 如 果 “ 传 感 器 数据 显示 接口 ”不 能 继续 显示 数据 ， 那 么 就 没有 必要 让 “传感器 
数据 算法 ”计算 温度 和 压力 。 所 以 ， 这 两 个 任务 之 间 的 接口 被 设计 为 不 带 回 复 的 同步 消息 通 
信 接 口 ， 如 图 18-16 的 并 发 通信 图 所 示 。 "传感器 数据 算法 ”计算 数据 、 发 送 消息 ， 然 后 在 继 
续 执 行 计 算 之 前 要 等 待 “传感器 数据 显示 接口 ”接收 消息 。“ 传 感 器 数据 算法 ”会 一 直 等 待 直 
到 “传感器 数据 显示 接口 ”完成 上 一 个 消息 的 显示 。 一 旦 “传感器 数据 显示 接口 ”接收 了 新 
到 来 的 消息 ,“ 传 感 器 数据 算法 ”就 会 从 等 待 中 被 释放 ， 并 计算 下 一 些 数据 ; 而 此 时 “传感器 
数据 显示 接口 ”正在 显示 上 一 些 数 据 。 这 意味 着 ， 数 据 的 计算 〈 一 个 计算 相关 的 活动 ) 可 以 
与 数据 的 显示 (一 个 VO 相关 的 活动 ) 过 程 同 时 进行 ， 这 就 避免 了 为 显示 数据 而 建立 一 个 不 
必要 的 消息 队列 。 因 此 两 个 任务 之 间 的 同步 接口 就 像 作 用 在 生产 者 任务 之 上 的 一 个 制 动 机 制 
一 样 。 


18.8.4 事件 同步 


共有 三 种 事件 同步 类 型 : 外 部 事件 、 
计时 器 事件 和 内 部 事件 。 外 部 事件 是 来 自 
于 外 部 对 象 的 事件 ， 通 常 是 来 自 于 外 部 IO 
设备 的 中 断 。 内 部 事件 指 源 任务 和 目标 任 
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图 18-16 不 带 回复 的 同步 消息 通信 示例 
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: DoorSensor 


«event driven» 
«input» 
: DoorSensorinterface 


务 之 间 的 内 部 同步 。 计 时 器 事件 则 指 一 个 
任务 的 周期 性 触发 。 在 UML 中 使 用 异步 消 
息 表 示 法 来 表示 一 个 事件 信号 。 

图 18-17 给 出 了 一 个 例子 ， 其 中 的 外 


Hardware / software boundary 


图 18-17 外 部 事件 示例 


ж: 上 图 中 表示 软 硬 件 边 界 的 虚线 仅 用 于 示意 目的 ， 
并 非 UML 表示 法 的 一 部 分 。 


部 事件 通常 是 来 自 于 输入 设备 的 硬件 中 断 。 当 “ 门 传感器 ”( Door Sensor ) 任务 «event 
driven»«external input device» 得 到 doorInput 输入 时 会 产生 一 个 中 断 ， 此 中 断 触 发 
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“ 门 传 感 器 接口 ”( Door Sensor Interface ) 任务 «event driven»«input», (Е 5 ВЕЈЕ 
读 取 门 输入 信号 doorInput。 这 一 交互 过 程 可 以 表示 为 : 来 自 于 设备 的 一 个 事件 信号 输 
和 人 入， 跟随 一 个 来 自 于 任务 的 读 取 操作 。 但 是 ,更 为 简洁 的 方法 是 将 此 交互 过 程 表 示 为 
一 个 由 设备 发 送 的 异步 事件 信号 ， 并 把 输入 数据 作为 参数 ， 如 图 18-17 中 的 并 发 通信 
图 所 示 。 | 

图 18-18 给 出 了 一 个 计时 器 事件 的 例子 。 数 字 时 钟 作为 一 个 外 部 计时 器 设备 ， 产 生 一 个 
计时 器 事件 (Timer Event ) 来 唤醒 “微波 炉 计时 器 ”( Microwave Timer ) «periodic» 任务 。“ 微 
波 炉 计时 器 ”任务 随后 执行 周期 性 活动 一 一 在 此 例 中 ,减少 一 秒 的 毫 饪 时 间 并 检查 豪 饪 是 否 
到 时 。 在 固定 的 时 间 间 隔 后 会 产生 一 个 计时 器 事件 。 

当 任 务 之 间 需 要 同步 但 不 进行 数据 通信 时 需 用 到 内 部 事件 同步 。 源 任务 发 出 事件 
信号 ， 目 标 任务 在 信号 到 达 之 前 保持 等 待 并 挂 起 。 如 果 已 经 接收 了 事件 信号 ， 那 么 目标 
任务 不 会 挂 起 。 事 件 信号 在 ОМІ 中 表示 为 不 包含 任何 数据 的 异步 消息 。 图 18-19 给 出 
了 一 个 例子 ， 其 中 的 拾取 - 放置 机 器 人 任务 发 出 事件 信号 partReady， 此 信和 号 唤醒 钻 孔 
机 器 人 ， 人 孔 机 器 人 完成 钻 孔 操作 然后 发 出 拾取 - 放置 机 器 人 正在 等 待 接收 的 事件 信和 号 
partCompleted。 
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Е 18-18 ”计时 器 事件 示例 图 18-19 内 部 事件 示例 


18.8.5 ”信息 隐藏 对 象 上 的 任务 交互 


任务 之 间 也 可 以 通过 被 动 信息 隐藏 对 象 交 换 信息 。 之 前 在 第 14 章 曾经 讨论 过 对 信息 隐藏 
对 象 的 访问 。 图 18-20 给 出 了 一 个 访问 被 动 信息 隐藏 对 象 任 务 的 例子 ， 其 中 “传感器 数据 算 
法 ”( Sensor Statistic Algorithm ) 任务 从 “传感器 数据 存储 ”( Sensor Statistic Repository ) 实体 
对 象 读 取 数 据 ， 而 “传感器 接口 ”( Sensor Interface ) 任务 则 更 新 此 实体 对 象 。 在 初始 化 并 发 
通信 图 中 ,“ 传 感 器 数据 算法 ”任务 向 实体 对 象 发 送 一 个 简单 的 “ 读 ”( Read ) 消息 ， 并 且 接 
收 一 个 “传感器 数据 ”( Sensor Data) 响应 ， 这 在 图 中 表示 为 简单 消息 ( 图 18-20a )。 由 于 该 
任务 是 从 被 动 信息 隐藏 对 象 读 取 数据 ， 其 接口 对 应 于 一 个 操作 调用 。 实 体 对 象 提 供 了 read 操 
作 ， 此 操作 被 “传感器 数据 算法 ”任务 调用 ， 响 应 sensorData 则 是 该 调用 的 输出 参数 。read 
操作 在 任务 的 控制 线程 中 执行 。 在 修正 后 的 并 发 通信 图 中 (图 18-20b )， 对 read 操作 的 调 
用 使 用 同步 消息 表示 法 描述 。“ 传 感 器 接口 任务 ”调用 “传感器 数据 存储 ”实体 对 象 提供 的 
write 操作 ， 其 中 sensorData 作为 输入 参数 。 

这 里 需要 注意 的 是 同步 消息 表示 法 在 两 个 并 发 任务 之 间 的 用 法 不 同 于 在 任务 和 被 动 对 象 
之 间 的 用 法 。 在 UML 中 虽然 二 者 看 起 来 十 分 相似 ， 即 使 用 一 个 实心 箭头 来 表示 ， 但 其 语义 
不 尽 相 同 。 两 个 并 发 任务 之 间 的 同步 消息 表示 法 表示 一 个 生产 者 任务 正在 等 待 一 个 消费 者 任 
务 的 响应 或 等 待 其 接收 生产 者 的 消息 ， 如 图 18-15 和 18-16 所 示 。 任 务 与 被 动 对 象 之 间 的 同步 
消息 表示 法 则 表示 一 个 操作 调用 ， 如 图 18-20 所 示 。 
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b) 修正 后 的 由 任务 调用 被 动 对 象 操作 的 并 发 通信 图 
图 18-20 ”任务 调用 被 动 对 象 操 作 的 示例 


18.8.6 ”修正 的 并 发 通信 图 


在 确定 了 任务 接口 之 后 ， 需 要 对 初始 的 并 发 通信 图 进行 修正 以 表示 不 同类 型 的 任务 接口 。 
图 18-21 给 出 了 一 个 修正 后 的 并 发 通信 图 的 例子 ， 它 是 “银行 系统 ”中 的 “ATM 客户 端 ” 子 
系统 。 在 该 例子 中 已 更 新 了 图 18-13 中 的 初始 化 并 发 通信 图 以 显示 所 有 任务 接口 。 第 21 章 将 
给 出 “ATM 客户 端 ” 的 设计 细节 。 


18.9 任务 接口 和 任务 行为 规约 


任务 接口 规约 (task interface specification, TIS) 描述 并 发 任务 的 接口 ， 它 是 类 接口 规约 
的 扩展 ,但 还 包含 了 专门 针对 任务 的 其 他 信息 ， 包 括 : 任务 结构 、 时 序 特征 、 相 对 优先 级 ， 
以 及 错误 检测 。 任 务 行为 规约 (task behavior specification, TBS ) 描述 任务 事件 的 顺序 逻辑 。 
任务 接口 定义 了 任务 之 间 的 交互 方式 。 任 务 结 构 描 述 了 如 何 使 用 任务 组 织 准 则 构造 任务 。 任 
务 时 序 特征 则 表示 任务 触发 频率 以 及 估计 的 执行 时 间 ， 该 信息 主要 用 于 实时 调度 的 目的 ， 因 
而 本 书 不 再 过 多 讨论 。 

我 们 将 TIS 与 任务 体系 结构 一 起 介绍 来 描述 每 个 任务 的 特征 。TBS 稍 后 在 软件 设计 细节 
部 分 介绍 ， 主 要 用 于 描述 任务 事件 顺序 逻辑 ， 即 任务 如 何 对 接收 到 的 输入 事件 做 出 响应 。 

任务 ( 主动 类 ) 与 被 动 类 之 间 的 差别 是 主动 类 中 只 包含 一 个 操作 ( 在 Java 语言 中 可 以 实 
现 为 一 个 гип 方法 )。 因 此 TIS 只 包含 一 个 操作 ， 而 不 是 像 一 般 被 动 类 那样 有 多 个 操作 。TIS 
定义 如 下 ， 其 中 前 五 个 定义 项 与 类 接口 规约 一 致 : 

e 名 称 

e 隐藏 的 信息 

ө 组 织 准 则 : 在 类 组 织 准 则 中 ， 仅 仅 角 色 (例如 输入 角色 input) 准则 被 使 用 ; 而 在 并 发 

任务 中 ， 需 要 增加 并 发 准则 〈 例如 事件 驱动 ) 

e 假设 

e 预期 的 变化 

о 任务 接口 : 任务 接口 的 定义 中 应 该 包含 以 下 信息 : 

e 消息 输入 与 输出 。 对 于 每 个 消息 接口 (输入 与 输出 ) 应 该 具有 以 下 描述 : 
> 接口 类 型 : 异步 ， 带 回复 的 同步 ， 不 带 回复 的 同步 
> 每 个 接口 支持 的 消息 类 型 : 消息 名 称 和 消息 参数 
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• 事件 信号 (输入 与 输出 )， 事 件 名 称 ， 事 件 类 型 : 外 部 、 内 部 、 计 时 器 。 
e 外 部 输入 或 者 输出 。 定 义 来 自 外 部 环境 的 输入 和 到 外 部 环境 的 输出 。 
• 引用 的 被 动 对 象 。 
。 被 此 任务 检测 到 的 错误 。 
本 节 描 述 了 在 任务 执行 过 程 中 可 以 检测 到 的 可 能 错误 。 
TBS 描述 了 任务 的 事件 顺序 逻辑 ， 即 任务 如 何 对 接收 到 的 消息 或 事件 输入 做 出 响应 ， 尤 
其 是 作为 每 个 输入 的 输出 结果 是 如 何 被 生成 的 。 事 件 的 顺序 逻辑 在 设计 软件 细节 时 定义 。 第 
21 章 针对 “银行 系统 ”给 出 任务 事件 顺序 逻辑 的 例子 。 


18.9.1 针对 银行 服务 任务 的 TIS 示例 


“银行 服务 ”任务 (第 21 ÆRE 18-21) 的 TIS 描述 如 下 : 
名 称 :“ 银 行 服务 ”( BankingService ) 
隐藏 的 信息 :“ 银 行 服务 ”处 理 ATM 交易 的 细节 
组 织 准则 : AEE: RE (service); 并 发 准则 : 按 需 驱动 
假设 : 交易 需要 顺序 处 理 
预期 的 变化 : 可 能 增加 新 的 交易 ; 可 能 从 顺序 服务 变更 为 并 发 服务 处 理 
任务 接口 : 
任务 输入 : 
带 回 复 的 同步 消息 通信 : 
消息 : 
• validatePIN 
输入 参数 ，cardId，PIN 
回复 : PINValidationResponse 
• withdraw 
输入 参数 : cardId，account#，amount 
回复 : withdrawalResponse 
• query 
输入 参数 : cardId，account# 
回复 : queryResponse 
• transfer 
输入 参数 : сага, fromAccount#, toAccount#, amount 
回复 : transferResponse 
任务 输出 : 
之 前 描述 过 的 消息 回复 
检测 到 的 错误 : 未 识别 的 消息 


18.9.2 ”针对 读 卡 器 接口 任务 TIS 的 示例 


以 下 给 出 读 卡 器 接口 任务 (第 21 BRA 18-21) 的 接口 规约 : 
名 称 : CardReaderInterface 
隐藏 的 信息 : 处 理 读 卡 器 输入 和 输出 的 细节 
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组 织 准 则 : 角色 准则 : 输入 /输出 ; 并 发 准则 : 事件 驱动 
假设 : 一 次 只 能 处 理 一 个 ATM 卡 的 输入 和 输出 
预期 的 变化 : 可 能 需要 从 АТМ 卡 中 读 取 附加 的 信息 
任务 接口 : 
任务 输入 : 
事件 输入 : 一 个 用 于 声明 卡 已 被 插入 的 读 卡 器 外 部 中 断 
外 部 输入 : cardReadInput 
不 带 回复 的 同步 消息 通信 : 
• eject 
• confiscate 
任务 输出 : 
341 外 部 输出 : сагаКеадетОошрш 
异步 消息 通信 : 
• cardInserted 
® cardEjected 
® cardConfiscated 
访问 的 被 动 对 象 : ATMCard 
检测 到 的 错误 : 未 识别 的 卡 ， 读 卡 器 故障 


18.10 Јама 中 并 发 任务 的 实现 


作为 任务 实现 的 例子 ， 考虑 Java 中 使 用 线程 实现 任务 。 在 Java 中 设计 线程 类 的 最 简单 方 
法 是 继承 Java Thread 类 ， 其 中 包含 一 个 称 为 run 的 方法 。 继 承 得 到 的 新 线程 类 必须 实现 run 
方法 ， 在 调用 时 run 方法 会 在 独立 的 控制 线程 中 执行 。 在 以 下 例子 中 ，ATM 控制 类 被 设计 
成 一 个 线程 ， 线 程 体 包含 在 гип 方法 中 。 通 常任 务 体 是 一 个 循环 ， 其 中 任务 会 等 待 外 部 事件 
(来 自 于 外 部 设备 或 者 计时 器 ) 或 等 待 来 自 于 生产 者 任务 的 消息 。 


public class ATMControl extends Thread{} 
public void run (){ 

while (true) 

//task body 

} 


18.11 АЖ 


在 任务 构造 阶段 ， 我 们 把 系统 构造 成 并 发 任务 并 且 定 义 任 务 接口 。 为 了 确定 并 发 任务 ， 
使 用 任务 组 织 准 则 将 面向 对 象 的 分 析 模 型 映射 成 并 发 任务 体系 结构 系统 。 同 时 ， 也 定义 了 任 
务 通 信和 同步 接口 。 每 个 任务 都 使 用 任务 组 织 准则 确定 。 一 个 针对 “自动 引导 车 辆 系统 ”的 
实时 软件 体系 结构 设计 实例 将 在 第 24 章 给 出 。 另 外 ， 一 个 针对 “银行 系统 ”中 “ATM 客户 
端 ” 子 系统 的 并 发 软件 设计 实例 在 第 21 章 给 出 。 
BAKFLMN MRAK AS UML 建 模 的 信息 可 以 参考 MARTE， 它 介绍 了 实时 和 敌人 式 
系统 的 UML 建 模 与 分 析 (Espinoza et al 2009 )。 更 多 关于 实时 软件 体系 结构 设计 的 信息 可 以 参 
Ж Gomaa( 2000 )。 如 果 要 使 并 发 任务 的 设计 更 加 高 效 ( 即 需 要 更 少 资源 )， 可 以 通过 应 用 任务 
集群 准则 ( 例如 顺序 、 时 序 或 控制 集群 ) 将 一 组 相关 任务 组 合成 一 个 集群 任务 ( Gomaa 2000 )。 
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练习 


选择 题 ( 每 道 题 选择 一 个 答案 ) 

. 主动 对 象 和 被 动 对 象 之 间 的 区 别 是 什么 ? 

(а) 主动 对 象 控制 被 动 对 象 

(b) 主动 对 象 没 有 控制 线程 ;被 动 对 象 具有 控制 线程 
(с) 主动 对 象 在 分 布 式 系统 中 执行 ;被动 对 象 则 在 集中 式 系统 中 执行 
(4) 主动 对 象 具有 控制 线程 ;而 被 动 对 象 不 具有 控制 线程 
什么 是 事件 驱动 输入 任务 ? 

(а) 每 几 秘 钟 执行 一 次 的 任务 

(b ) 控制 其 他 任务 的 任务 

(с) 从 产生 中 断 的 外 部 设备 接收 输入 的 任务 

(4) 用 于 检查 是 否 存 在 来 自 外 部 设备 新 的 输入 的 任务 


— 


N 


3. 什么 是 周期 性 任务 ? 
(а) 对 每 个 接收 到 的 消息 做 出 响应 的 任务 (b) 被 计时 器 事件 触发 的 任务 
(с) 被 外 部 事件 触发 的 任务 (4) 被 输入 事件 触发 的 任务 
4. 什么 是 按 需 驱 动 的 任务 ? 


(а) 对 每 个 接收 到 的 消息 做 出 响应 的 任务 

(b) 被 来 自 于 其 他 任务 的 内 部 消息 或 事件 触发 的 任务 
(с) 被 外 部 事件 触发 的 任务 

Cd) 被 输入 事件 触发 的 任务 


5. 什么 是 控制 任务 ? 

(а) 控制 其 他 任务 的 任务 (b) 执行 状态 表 的 任务 

Cc) 按 需 执行 的 任务 (а) 控制 VO 设备 的 任务 

6. 什么 是 用 户 交 互 任务 ? 

(а) 与 VO 设备 交互 的 任务 (b) 与 用 户 交 互 的 任务 

(с) 与 用 户 顺 序 交互 的 任务 (4) 与 用 户 并 发 交互 的 任务 

7. 对 于 集中 式 控制 体系 结构 模式 来 说 下 面 哪个 表述 是 对 的 ? 

(а) 控制 被 分 配 在 多 个 控制 构件 之 中 (b ) 控制 整个 系统 并 提供 执行 顺序 


(с) 通过 协调 多 个 控制 构件 提供 整体 控制 (d) 对 多 个 IO 对 象 提供 整体 控制 
. 对 于 分 布 式 控制 体系 结构 模式 来 说 下 面 哪 个 表述 是 正确 的 ? 
(а) 控制 功能 分 别处 于 多 个 控制 构件 中 (b) 对 来 自 客户 端子 系统 的 多 个 请 求 做 出 响应 
(с) 通过 协调 多 个 控制 构件 提供 整体 控制 (а) 对 多 个 VO 对 象 提供 分 布 式 控制 
. 对 于 层次 化 控制 体系 结构 模式 来 说 以 下 哪个 表述 是 正确 的 ? 
(a) 控制 功能 分 别处 于 多 个 控制 构件 中 Cb) 对 多 个 客户 端子 系统 提供 整体 控制 
(с) 通过 协调 多 个 控制 构件 提供 整体 控制 (а) 对 多 个 IO 对 象 提供 分 布 式 控制 
10. 以 下 哪个 不 属于 事件 同步 之 列 ? 
(a) 外 部 事件 (b) 内 部 事件 
(с) 计时 吉事 件 (а) 用 户 事件 


со 
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设计 软件 产品 线 体 系 结构 





一 个 软件 产品 线 (software product line, SPL) 包含 一 组 软件 系统 ， 这 些 系统 之 间 有 着 
部 分 相同 的 功能 和 部 分 可 变 的 功能 (Clements and Northop 2002; Parnas 1979; Weiss and Lai 
1999)。 软 件 产品 线 工 程 涉及 这 一 组 软件 系统 的 需求 、 体 系 结构 和 构件 实现 ， 从 中 可 以 派生 并 
配置 出 各 种 软件 产品 〈《 即 这 组 软件 系统 的 成 员 )。 由 于 可 变性 管理 所 增加 的 复杂 性 ， 软 件 产品 
线 开 发 中 单个 软件 系统 的 开发 问题 也 增多 了 。 

与 单个 软件 系统 一 样 ， 我 们 也 可 以 通过 考虑 产品 线 的 需求 模型 、 静 态 模型 和 动态 模型 等 
多 个 视图 来 更 好 地 理解 一 个 软件 产品 线 。 开 发 人 员 可 以 使 用 像 UML 那样 的 图 形 建 模 语言 来 开 
发 、 理 解 这 些 视图 并 在 它们 之 间 建 立 通信 。SPL 的 众多 视图 中 最 为 重要 的 一 个 就 是 特征 建 模 
视图 。 特 征 模 型 对 于 管理 产品 线 可 变性 以 及 派生 产品 线 成 员 十 分 关键 ， 因 为 它 从 共性 和 可 变 
性 的 角度 描述 了 产品 线 需 求 并 定义 了 产品 线 中 的 依赖 关系 。 此 外 ， 最 好 能 建立 一 个 能 促进 软 
件 演化 的 开发 方法 ， 由 此 可 以 使 用 特征 驱动 的 演化 方式 来 处 理 软 件 开发 及 其 后 续 的 维护 工作 。 

本 章 概 述 了 使 用 基于 UML 的 产品 线 软 件 工程 (Product Line UML-based Software, 
PLUS ) 方法 来 设计 SPL 体系 结构 。PLUS 在 COMET 方法 的 基础 之 上 对 每 种 建 模 视图 增加 
了 可 变性 维度 。 关 于 SPL 的 详细 设计 ， 作 者 在 另 一 著作 (Gomaa 2005а) 中 做 了 详尽 的 介绍 。 
19.1 节 描 述 SPL 工程 中 演化 软件 过 程 模型 。19.2 节 描 述 SPL 的 用 例 建 模 和 特征 建 模 。19.3 节 
描述 SPL 的 静态 和 动态 建 模 。19.4 节 描 述 状 态 图 中 如 何 处 理 可 变性 。19.5 节 描 述 设 计 模型 中 
可 变性 的 管理 。 


19.1 演化 软件 产品 线 工 程 


SPL 工程 的 软件 过 程 模型 是 一 个 高 度 迭 代 的 软件 过 程 ， 它 没有 传统 的 软件 开发 和 软件 维 
护 之 间 的 明确 界限 。 此 外 ， 由 于 SPL 中 新 的 软件 系统 是 从 原 有 系统 中 衍生 而 来 ， 所 以 该 过 程 
具有 SPL 的 特点 并 包含 了 两 个 主要 过 程 (图 19-1): 

产品 线 用例 模 型 

产品 线 分 析 模 型 
= 产品 线 软 件 体系 结构 

人 需求 软件 产品 线 可 复 用 构件 类 型 

(领域 ) 工程 
产品 线 

工程 师 










应 用 工程 师 





未 满足 的 需求 、 错 误 、 适 应 
图 19-1 软件 产品 线 的 演化 软件 过 程 模 型 
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1) SPL 工程 (也 称 作 领域 工程 )。 开 发 产品 线 多 视图 模型 来 处 理 SPL 中 的 多 个 视图 。 开 
发 产品 线 多 视图 模型 、 产 品 线 体 系 结构 以 及 可 复 用 构件 (在 Clements and Northop[2002] 中 称 
作 核 心 资产 ) 并 将 它们 保存 在 产品 线 资产 库 中 。 

2) 软件 应 用 工程 。 一 个 软件 应 用 的 多 视图 模型 是 从 SPL 多 视图 模型 中 派生 出 的 一 个 独 
立 的 产品 线 成 员 。 用 户 从 产品 线 中 挑选 所 需 特征 。 如 果 给 定 一 些 特征 ， 那 么 就 能 对 产品 线 的 
模型 和 体系 结构 做 出 调整 和 裁剪 ， 从 而 得 到 一 个 应 用 体系 结构 。 该 体系 结构 确定 了 用 来 派生 
及 配置 出 可 执行 应 用 的 那 部 分 可 复 用 构件 。 


19.2 软件 产品 线 的 需求 建 模 


对 于 单个 系统 来 说 ， 用 例 建 模 是 软件 功能 性 需求 的 主要 描述 手段 。 而 对 于 SPL 来 说 ， 特 
征 建 模 则 是 需求 建 模 的 另 一 个 重要 部 分 。 特 征 建 模 的 优势 在 于 可 以 从 共性 功能 、 可 选 功能 和 
可 替换 功能 的 角度 来 区 分 产品 线 中 不 同 的 成 员 。 


19.2.1 软件 产品 线 的 用 例 建 模 


一 个 系统 的 功能 性 需求 是 通过 用 例 和 参与 者 来 定义 的 ( 见 第 6 章 )。 对 于 单个 系统 来 说 ， 
所 有 的 用 例 都 是 必需 的 。 在 一 个 SPL 中 ， 只 有 部 分 用 例 ( 也 称 为 核心 用 例 ) 才 是 所 有 产品 
线 成 员 所 必需 的 。 而 一 些 用 例 是 可 选 的 ， 因 为 只 有 部 分 产品 线 成 员 需 要 它们 ; 另 一 些 用 例 是 
可 替换 的 〈 即 不 同 产品 线 成 员 需 要 使 用 某 一 用 例 的 不 同 版 本 )。 在 UML 中 ， 用 例会 用 构造 型 
«kernel», «optional» 或 者 «alternative 来 标记 ( Gomaa 2005а )。 此 外 ， 可 以 使 用 可 变 点 来 
使 用 例 具 有 可 变性 ， 可 变 点 指明 了 用 例 中 可 引入 的 可 变性 的 地 方 ( Gomaa 2005а ; Jacobson, 
Griss, and Jonsson 1997; Webber and Gomaa 2004 )。 

图 19-2 给 出 了 一 个 银行 SPL 的 核心 和 可 选 的 产品 线 用 例 。 这 个 SPL 的 核心 用 例 包含 了 
人 允许 客户 验证 PIN 码 、 取 款 、 查 询 账 户 和 账户 间 转 账 等 (如 第 6 章 和 第 21 章 所 述 )。 可 选用 
例 则 用 来 “打印 结算 单 ”( Print Statement ) 和 “存款 ”( Deposit Funds )， 而 其 他 的 可 选用 例 与 
ATM 操作 人 员 维护 相关 ， 用 于 “启动 ”( Startup ) “XA” (Shutdown ) 和 给 ATM“ 添 加 现金 ” 
(Ада Cash ) (尽管 图 19-2 中 没有 显示 ， 但 是 这 些 用 例 在 第 21 章 的 用 例 案例 研究 中 会 介绍 )。 
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核心 用 例 和 可 选用 例 中 都 有 可 变 点 。 例 子 中 的 一 个 可 变 点 是 显示 的 提示 语言 。 因 为 “ 银 
行 系统 ”的 产品 将 会 部 署 在 不 同 的 国家 ， 所 以 每 个 银行 都 要 选择 合适 的 提示 语言 。 默 认 语言 
是 英语 ， 可 选 语言 有 法 语 、 西 班 牙 语 和 德语 。 在 “验证 РІМ 码 ”( Validate PIN) 用 例 中 存在 
一 个 可 变 点 的 例子 ， 其 中 可 变 点 存在 于 所 有 向 客户 显示 信息 的 地 方 。 这 种 可 变 点 具有 强制 选 
择 性 ( mandatory alternative )， 意 味 着 在 诸多 选项 中 必须 做 出 一 个 选择 。 
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“验证 PIN 码 ” 用 例 中 的 可 变 点 : 
名 称 : 显示 语言 。 
功能 类 型 : 强制 选择 性 。 


BRE: 35 8. 
功能 描述 : 显示 消息 的 语言 存在 多 个 选择 。 默 认为 英语 ， 互 斥 可 选 的 有 法 语 、 西 班 
牙 语 和 德语 。 





19.2.2 ”特征 建 模 


特征 建 模 是 一 种 重要 的 产品 线 工程 的 建 模 视 图 ( Kang et al.1990 )， 因 为 它 描述 了 SPL 的 
可 变性 。 通 过 分 析 特 征 可 将 其 分 类 为 共性 特征 ( 为 所 有 产品 线 成 员 所 需 )、 可 选 特征 ( 只 为 部 
分 产品 线 成 员 所 需 )、 可 替换 特征 ( 需 在 多 个 选项 中 做 出 一 个 选择 ) 和 先决 特征 ( 依赖 于 其 他 
特征 )。 特 征 建 模 的 关键 是 捕获 像 可 选 特征 和 可 替换 特征 那样 的 可 变性 ， 因 为 正 是 由 于 可 变 
性 ， 产 品 线 成 员 彼 此 之 间 才 得 以 有 所 区 别 。 

特征 广泛 使 用 于 产品 线 工 程 ， 却 不 常用 在 UML 中 。 为 了 有 效 建 模 产品 线 ， 很 有 必要 将 
特征 建 模 概 念 引 入 UML。 我 们 利用 元 类 的 概念 使 PLUS 方法 中 的 UML 包含 特征 。 在 此 过 
程 中 ， 可 使 用 UML 静态 建 模 表 示 法 来 建 模特 征 ， 并 用 构造 型 kcommon feature», «optional 
feature» 和 «alternative feature» 来 对 特征 加 以 区 分 (Gomaa 2005а )。 特 征 之 间 的 依赖 用 名 为 
依赖 (require) 的 关联 关系 表示 ， 例 如 “问候 ”( Greeting ) 特征 依赖 于 “语言 ”( Language ) 
特征 。 此 外 ， 可 以 用 元 类 及 构造 型 ( ЩП «zero-or-one-of feature group» 或 《exactly-one-of 
feature group» ) ( Gomaa 2005a ) 来 建 模 特征 组 。 在 用 户 为 产品 线 成 员 选 择 某 个 特征 〈 例如 相 
互 独立 的 特征 ) 时 ， 特 征 组 对 用 户 的 挑选 方式 加 以 了 约束 。 我 们 将 一 个 特征 组 建 模 为 若干 特 
征 的 一 个 聚合 ， 这 是 因为 一 个 特征 是 一 个 特征 组 的 一 部 分 。 

图 19-3 给 出 了 银行 SPL 的 特征 模型 。 共 性 特征 是 “银行 系统 核心 ”( Banking System 
Kernel )， 它 提供 了 АТМ 的 核心 功能 ， 对 应 于 图 19-2 中 的 四 个 核心 用 例 。“ 存 款 ”( Deposit ) 


«optional feature» 
Statement 
«optional feature» 
Deposit «parameterized 
feature» 
«optional feature» 
Greeting 
«default 


Max Pin Attempts 
{default = 3} 

feature» 

English 










«common 
feature» 
Banking System 
Kernel 























«exactly-one-of 
feature group» 
Language 









«optional feature» 
Maintenance 














«alternative 
feature» 
French 


«alternative 
feature» 
Spanish 


«alternative 
feature» 
German 






Р 19-3 UML 中 的 特征 和 特征 组 
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特征 对 应 于 图 19-2 中 可 选 的 “存款 ”( Deposit Funds ) 用 例 ， 它 是 一 个 依赖 于 核心 特征 的 可 
选 特征 。 类 似 地 ,“ 结 算 单 ”( Statement ) 也 是 一 个 可 选 特征 ， 对 应 于 可 选 的 “打印 结算 单 ” 
( Print Statement ) 用 例 。“ 语 言 ”( Language ) 是 一 个 具有 “ 选 一 ”约束 ( exactly-one-of ) 的 特 
征 组 ， 对 应 于 用 例 模 型 中 的 “语言 ”( Language ) 可 变 点 。 这 个 特征 组 包含 默认 特征 “英语 ” 
( English ) 和 可 替换 特征 “西班牙 滞 ”( Spanish )、“ 法 语 ”( French ) 或 者 “德语 ”( German )。 
还 有 一 个 针对 “最 大 PIN 码 尝试 次 数 ”( Max PIN Attempts ) 的 参数 化 特征 ， 它 设置 了 在 一 台 
ATM 机 上 的 最 大 错误 PIN 码 输入 次 数 ， 默 认 值 为 3。 另 一 个 可 选 特征 是 “问候 ”特征 ， 它 依 
赖 于 “语言 ”特征 ， 对 应 于 “问候 ”可 变 点 。ATM 可 以 对 客户 输出 一 个 用 适当 语言 显示 的 可 
选 的 问候 消息 。 

在 单个 系统 中 ， 用 例 用 来 确定 系统 的 功能 性 需求 ; 它们 在 产品 线 中 也 有 相同 作用 。Griss 
( Griss, Favaro, and d’Alessandro 1998 ) 指出 了 用 例 分 析 的 目的 是 充分 理解 功能 性 需求 ， 而 特 
征 分析 的 目的 是 为 了 复 用 。 用 例 和 特征 互相 补充 ， 因此， 可 选 和 可 替换 用 例 分 别 映射 到 可 选 
和 可 替换 特征 ， 相 对 地 ， 用 例 的 可 变 点 也 会 映射 到 特征 上 (Gomaa 2005a)。 

用 例 和 特征 的 关系 可 以 用 特征 /用例 关 系 表 来 描述 ， 如 表 19-1 所 示 。 对 于 每 一 个 特征 ， 
都 有 相关 的 用 例 来 描述 。 对 于 从 可 变 点 派生 出 的 特征 ， 表 中 也 列 出 了 可 变 点 的 名 称 。“ 银 
行 系统 核心 ”特征 与 “验证 PIN 码 ”( Validate PIN ) “查询 账户 ”(Query Account), “4% 
账 ”( Transfer Funds) 以 及 “取款 ”( Withdraw Funds) 核心 用 例 相 关 。“ 存 款 ”( Deposit ) 
和 “结算 单 ” 可 选 特征 分 别 对 应 于 “存款 ”( Deposit Funds) 和 “打印 结算 单 ” 可 选用 例 。 
“维护 ”( Maintenance ) 特征 对 应 于 АТМ 操作 人 员 维 护 用 例 的 “启动 ”(Startup ) “关闭 ” 
(Shutdown ) 和 “添加 现金 ”( Ааа Cash )。 可 选 的 “问候 ”特征 和 参数 化 的 “最 大 PIN 码 尝 
试 次 数 ”特征 对 应 于 验证 PIN 码 用 例 的 可 变 点 。" 英 语 ”"、“ 法 语 ”"、“ 德 语 ” 和 “西班牙 语 ” 等 
可 替换 语言 特征 与 “银行 系统 ”SPL 的 所 有 用 例 中 的 “语言 ”可 变 点 关联 。 这 个 可 变 点 影响 
ATM 机 的 所 有 提示 信息 。 


表 19-1 特征 /用 例 关系 表 
SERM 
共性 


银行 系统 核心 





不 мм 


Е 存款 可 选 
结算 单 
维护 ШЕТ 启动 可 选 

关闭 ШЕ 

添加 现金 БЕ: 
英语 显示 语言 
西班牙 语 可 替换 可 变 点 显示 语言 
法 语 可 替换 显示 语言 
问候 ШТ 问候 


最 大 PIN 码 尝试 交 数 TEA PIN 码 尝试 
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19.3 软件 产品 线 的 分 析 建 模 


对 于 单个 系统 ， 分 析 建 模 包 含 静 态 和 动态 建 模 。 然 而 在 本 章 ， 这 两 种 建 模 方法 都 需要 涉 
及 建 模 SPL 的 可 变性 。 


19.3.1 软件 产品 线 的 静态 建 模 


在 单个 系统 中 ， 类 根据 它 扮 演 的 角色 进行 分 类 。 根 据 应 用 类 在 应 用 中 所 扮演 的 角色 ,我 
们 使 用 构造 型 来 对 其 进行 分 类 ( 见 第 8 章 )， 如 «entity class», «control class» 或 者 «boundary 
class»》。 在 建 模 SPL 过 程 中 ， 根 据 类 复 用 特性 ， 我 们 也 可 使 用 构造 型 kkernel»》、《optional》 和 
«variant» 来 对 其 分 类 。 在 ОМІ 中 ， 一 个 建 模 元 素 可 以 有 多 个 构造 型 。 因 此 ， 可 以 用 一 个 构 
造型 来 表示 复 用 特性 ， 同 时 用 另 一 个 构造 型 来 表示 建 模 元 素 扮演 的 角色 (Gomaa 2005a)。 一 个 
类 在 应 用 中 扮演 的 角色 和 复 用 特性 是 正 交 的 。 

图 19-4 给 出 了 核心 、 可 选 和 变 体 实 体 类 的 例子 。 “ATM” (АТМ Сага) ЯП “АТМ 
现金 ”( ATM Cash) 是 核心 实体 类 ， 因 为 每 个 SPL 成 员 都 需要 它们 。 “АТМ 问候 ”( ATM 
Greeting) 实体 类 是 可 选 类 ， 因 为 它 对 应 于 可 选 的 “问候 ”( Greeting ) 特征 。 对 于 “语言 
(Language ) 特征 组 ， 有 一 个 名 为 “显示 咽 提 示 ”( Display Prompt) 的 抽象 核心 父 类 ， 它 拥有 
可 变 的 子 类 ， 每 个 子 类 包含 了 对 应 于 每 种 语言 特征 的 特定 语言 提示 。 每 一 个 类 都 用 两 个 构造 
型 描述 : 描述 类 实体 的 角色 构造 型 和 描述 核心 、 可 选 或 者 变 体 等 可 变 类 型 的 复 用 构造 型 。 


«кете» 
«ИО» э 
«optional» «kernel» 
Cetaco a ых ыы 
interaction» control» 
Operator ATMControl 
«kernel» Interaction 
« 为 
«kermel 
» 
Custom 










«kernel» 
«entity» 


DisplayPrompts 


«variant» «variant» 

«entity» «entity» 

French Spanish 
DisplayPrompts| |DisplayPrompts| 


И 19-4 产品 线 类 中 的 角色 和 复 用 构造 型 













“en 
DisplayPrompts 
19.3.2 ”软件 产品 线 的 动态 交互 建 模 


SPL 的 动态 建 模 使 用 一 个 称 为 演化 动态 分 析 的 和 迭代 性 策略 ， 它 帮助 设计 人 员 确 定 每 个 特征 
在 软件 体系 结构 上 的 动态 影响 ， 这 会 使 设计 人 员 添 加 新 的 构件 并 调整 已 有 构件 。 核 心 系统 是 产 
品 线 中 规模 最 为 精简 的 成 员 。 在 某 些 产品 线 中 ， 核 心 系统 仅 包含 核心 对 象 ;而 其 他 产品 线 中 ， 
除了 核心 对 象 外 还 会 包括 一 些 默认 对 象 。 核 心 系统 是 通过 考虑 每 个 产品 线 成 员 都 需要 的 核心 用 
例 而 开发 出 来 的 。 对 于 每 一 个 核心 用 例 ， 可 以 使 用 通信 图 来 描述 实现 用 例 所 需要 的 对 象 ( 使 用 
第 9 章 和 第 11 章 的 方法 )。 通 过 整合 基于 核心 用 例 的 通信 图 可 以 确定 核心 系统 (使 用 第 13 章 
的 方法 ) 的 所 有 对 象 和 它们 之 间 的 消息 通信 。 下 一 步 便 是 确定 实例 化 对 象 所 需 的 类 。 

软件 产品 线 演 化 方法 由 核心 系统 开始 ， 而 后 考虑 可 选 和 /或 可 替换 特征 的 影响 (Gomaa 
2005a)。 此 过 程 会 在 产品 线 体系 结构 中 添加 可 选 或 变 体 对 象 。 通 过 考虑 可 变 的 〈 可 选 的 和 可 
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替换 的 ) 用 例 以 及 所 有 核心 或 可 变 的 用 例 中 的 可 变 点 可 完成 这 个 分 析 。 针 对 每 一 个 可 选 或 可 
替换 用 例 ， 可 以 画 一 个 包含 新 的 可 选 或 变 体 对 象 的 交互 图 。 被 可 变 场 景 影响 的 核心 或 可 选 对 
象 就 是 变 体 对 象 ， 所 以 ， 在 此 过 程 中 要 对 这 些 对 象 做 一 些 调整 。 

图 19-5 给 出 了 一 个 例子 ， 该 例 演 示 了 银行 SPL 的 АТМ 客户 端的 动态 演化 分 析 。 图 19-5а 
描述 了 实现 “验证 PIN 码 ” 用 例 的 两 个 软件 对 象 (“ATM 控制 ”( АТМ Control) 和 “客户 交互 ” 
(Customer Interaction ) )。 考 虑 到 “问候 ”( Greeting ) 和 “语言 ”( Language ) 特征 对 于 “验证 
PIN 码 ”( Validate PIN ) 的 基于 用 例 的 通信 图 的 影响 ( 图 19-5b )， 我 们 增加 了 可 选 的 “ATM 问 
候 ”( АТМ Greeting ) 实体 对 象 以 及 某 个 合适 的 “显示 器 提示 ”( Display Prompt ) 变 体 实体 对 象 
(如 “法 语 显示 器 提示 ”( French Display Prompt ))。“ 客 户 交 互 ”( Customer Interaction ) 对 象 能 
访问 这 两 个 对 象 。“ATM 控制 ”对 象 向 “客户 交互 ”对 象 发 送 提示 内 容 请 求 。 ”客户 交互 ”对 
象 从 “显示 器 提示 ”对 象 获取 提示 内 容 之 后 ， 便 向 客户 显示 该 内 容 。 对 于 提示 问候 ,“ 客 户 交 
互 ”对 象 会 从 “ATM 问候 ”对 象 获 取 问 候 内 容 ， 并 在 ATM 空闲 时 将 其 显示 在 显示 器 上 。 
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Р1.1: Read Prompt (prompt id) 








G1.2: Greeting Text 


«entity» «entity» 
: ATMGreeting : FrenchPrompts 


b) 
图 19-5 “验证 PIN 码 ” 通 信 图 中 的 “问候 ”和 “语言 ”特征 的 动态 演化 分 析 

















表 19-2 银行 SPL 的 特征 / 类 依赖 关系 表 





特征 名 称 


















银行 系统 核心 读 卡 器 接 = 核心 
АТМ 卡 核心 
ATM 控制 核心 ， 参 数 化 
客户 交互 核心 ， 参 数 化 
显示 器 提示 核心 抽象 
АТМ 交易 核心 抽象 





ATM 现金 核心 
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(Ж) 
特征 名 称 类 参数 


= 
吐 钞 器 接口 核心 
存款 可 选 ATM 控制 核心 ， 参 数 化 存款 条 件 
读 卡 器 接口 可 选 
存款 交易 可 选 
结算 单 事务 可 选 
操作 员 交 互 可 选 


英语 英语 显示 器 提示 
西班牙 语 西班牙 语 显示 器 提示 
法 语 变 体 
德语 
问候 ATM 问候 可 选 
客户 交互 核心 ， 参数 化 问候 条 件 
最 大 PIN 码 尝试 次 数 PIN 码 尝试 


特征 和 类 之 间 的 关系 可 以 使 用 特征 /类 依赖 关系 表格 描述 。 表 格 展示 了 对 于 每 一 个 特征 ， 
实现 它 的 类 、 类 复 用 类 型 ( 核心、 可 选 或 者 可 变 ) 以 及 参数 化 类 的 类 参数 ( 如 果 是 一 个 参数 
化 类 的 话 )。 用 动态 演化 分 析 完 成 动态 影响 分 析 之 后 ， 就 可 制定 出 该 表格 。 


19.4 ”软件 产品 线 的 动态 状态 机 建 模 


在 设计 可 变 的 类 时 ， 主 要 考虑 采用 两 种 方法 : 特 化 或 者 参数 化 。 当 变化 相对 较 少 时 特 化 方 
法 是 有 效 的 ， 在 这 种 情况 下 ， 特 化 类 的 数量 是 可 控 的 。 然 而 在 产品 线 开 发 中 ， 有 可 能 存在 大 量 的 
可 变性 。 第 10 章 介 绍 了 如 何 使 用 状态 机 和 状态 图 来 建 模 和 描述 状态 相关 的 控制 类 ， 我 们 考虑 一 
下 它 的 可 变性 问题 。 该 可 变性 既 可 以 使 用 参数 化 的 状态 机 来 处 理 ， 也 可 用 多 个 特 化 的 状态 机 来 处 
理 。 产 品 线 可 能 采用 集中 式 或 者 分 布 式 的 方法 ， 不 同 的 方法 会 导致 多 个 不 同 的 状态 相关 的 控制 
类 ， 我 们 可 以 把 每 个 控制 类 建 模 为 它 自身 的 一 个 状态 机 。 接 下 来 讨论 的 是 状态 相关 类 的 可 变性 。 

为 了 确定 状态 机 的 可 变性 和 演化 方式 ， 有 必要 明确 可 选 的 状态 、 事 件 、 状 态 转移 以 及 动 
作 ， 并 且 要 进一步 决定 使 用 状态 机 继承 ( 即 前 文中 的 特 化 ) 还 是 状态 机 参数 化 来 表示 可 变性 。 
使 用 继承 的 问题 是 需要 为 每 一 个 可 选 或 可 替换 特征 〈 或 者 是 特征 组 合 ) 建 模 一 个 状态 机 ， 这 很 
容易 使 继承 的 状态 机 数量 组 合 爆炸 。 例 如 ， 如 果 只 有 3 个 会 影响 状态 机 的 可 选 特征 ， 那 么 将 
会 有 8 种 可 能 的 特征 组 合 ， 相 应 有 8 个 变 体 状态 机 。 如 果 有 10 个 可 选 特征 ， 那 么 将 会 有 超过 
1000 个 变 体 状态 机 。 然 而 ， 使 用 参数 化 状态 机 可 以 轻松 地 对 10 个 可 选 特征 建 模 ， 因 为 只 需 将 
它们 建 模 为 一 个 参数 化 状态 机 并 让 它 包 含 10 个 依赖 于 特征 的 状态 转移 、 状 态 或 者 动作 即 可 。 

参数 化 状态 机 包含 了 依赖 于 特征 的 状态 、 事 件 以 及 转移 ， 通 常设 计 这 样 一 个 状态 机 会 更 
为 有 效 。 对 一 个 事件 加 上 一 个 布尔 值 特征 条 件 来 控制 它 能 否 进入 一 个 状态 ， 由 此 可 以 表示 可 
选 的 状态 转移 。 也 可 以 通过 一 个 布尔 值 特征 条 件 来 控制 可 选 的 动作 ， 如 果 在 挑选 某 SPL 成 员 
的 特征 时 选中 相关 特征 ， 那 么 其 相关 的 布尔 值 为 真 ， 反 之 则 为 假 。 

下 面 给 出 依赖 于 特征 的 状态 转移 和 动作 的 一 个 例子 ， 这 个 例子 来 自 于 “微波 炉 产 品 
线 "。 图 19-6 描述 了 微波 炉 状态 图 中 的 三 个 状态 (“ЖЖ Е” (Cooking), “YE EE” (Ready 
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to Соок) 1 “МГ” (Door Shut with Item )) ( 这 个 例子 的 核心 状态 图 与 第 10 章 的 第 
10.2.2 节 中 所 描述 的 相同 ) “分钟 加 热 ”( Minute Plus) 是 一 个 把 食物 豪 饪 一 分 钟 的 可 选 特 
征 。 在 状态 图 中 ,“ 按 下 分 钟 加 热 ”( Minute Pressed) АМ “ГЕЯ” ЖЕ “И” 
状态 的 状态 转移 ， 它 依赖 于 特征 。 该 状态 转移 由 图 19-6 的 minuteplus 特征 条 件 所 控制 ， 如 
果 选 择 了 这 样 一 个 可 选 特征 ， 那 么 它 的 布尔 值 为 真 。 在 图 19-6 中 还 有 些 依赖 于 特征 的 动 
作 ， 如 “ 亮 灯 ”(Switch Оп) (“ж FE” 

状态 的 进入 动作 ) 和 “ 灭 灯 ”(Switch Cooking 
Off) (“ 豪 饪 ”状态 的 转移 动作 )， 只 有 РЕ 
当 “ 灯 ”( light ) 特征 控制 的 条 件 为 真 | star Cooking, 
时 ， 这 些 动作 才 会 生效 。 同 样 地 ， 只 要 [Semen On Mandl 
= “епу” ( beep ) 控制 的 特征 条 件 为 真 Time Entered 
时 ,“ 蜂 鸣 ” 动 作 才 会 生效 。 这 样 ， 如 
果 用 户 在 定制 产品 线 成 员 时 挑选 了 某 可 
选 特征 ， 那 么 它 的 特征 条 件 就 为 真 〈 意 

味 着 相应 的 转移 或 动作 生效 ) ; 反之 则 图 19-6 依赖 于 特征 的 状态 转移 和 动作 

5 (意味 着 相应 的 转移 或 动作 失效 )。 

同样 ， 如 果 引 入 可 替换 的 状态 或 转移 的 状态 机 ， 也 可 以 很 精确 地 建 模特 征 交 互 的 影响 情况 。 
通常 来 说 ， 设 计 参 数 化 状态 图 比 设计 特 化 状态 图 更 易于 管理 。 


19.5 软件 产品 线 的 设计 建 模 


在 设计 建 模 中 ， 可 变性 是 通过 开发 变 体 和 参数 化 构件 来 处 理 的 。 某 些 软件 体系 结构 模式 
由 于 本 身 支 持 可 变性 和 演化 ， 所 以 特别 适用 于 SPL, 


19.5.1 建 模 基于 构件 的 软件 体系 结构 






Timer Expired/ 
Switch Off [light] 


ыы Door Shut 
Minute Pressed [minuteplus]/ | with Item 
Start Minute 


Cooking 




















Exit/ 
Stop Cooking, 
Beep [beeper] 





Start/ 
Start Timer 


一 个 软件 构件 的 接口 规约 独立 于 它 的 实现 ， 但 不 同 于 类 ， 需 要 明确 地 设计 出 构件 的 请 求 
接口 与 其 供给 接口 。 这 一 点 在 以 体系 结构 为 中 心 的 演化 中 非常 重要 ， 因 为 我 们 很 有 必要 了 解 
一 个 构件 的 变化 会 如 何 影响 与 之 交互 的 其 他 构件 。 

基于 构件 的 软件 体系 结构 的 建 模 能 力 对 产品 线 工 程 非常 有 价值 ， 这 便于 开发 核心 、 可 选 
和 变 体 构 件 、 构 建 插 拔 兼容 ( plug-compatible ) 的 构件 以 及 实现 构件 接口 的 继承 。 设 计 构 件 
有 多 种 方式 。 如 果 可 能 的 话 ， 最 好 能 够 设计 揪 拔 兼容 的 构件 ， 这 样 ， 一 个 构件 的 请 求 端口 可 
以 和 其 他 交互 构件 的 供给 接口 相 兼容 。 考 虑 图 19-7 中 的 情况 ， 其 中 一 个 生产 者 构件 需要 与 不 
同 的 产品 线 成 员 中 的 各 个 可 替换 消费 者 构件 相连 接 。 如 果 可 能 的 话 ， 最 佳 方案 是 将 所 有 的 消 
费 者 构件 设计 成 具有 相同 供给 接口 的 构件 ， 这 样 生产 者 构件 无 需 改变 请 求 接口 即 可 连接 所 有 
的 消费 者 构件 。 在 图 19-7 中 ,“ 客 户 交 互 ”(Customer Interaction) 构件 要 与 “显示 器 提示 ” 
( Display Prompt ) 构件 的 任 一 变 体 构件 连接 ， 如 “英语 显示 器 提示 ”( English Display Prompt ) 
和 “法 语 显示 器 提示 ”( French Display Prompt ) ( 各 自 对 应 于 图 19-3 中 的 默认 英语 特征 和 可 
替换 的 法 语 特征 )。 图 19-7 所 示 的 构件 接口 指明 了 三 种 操作 : 初始 化 构件 、 读 取 给 定 提示 Id 
的 提示 内 容 以 及 添加 新 的 提示 。 每 个 实现 该 接口 的 默认 或 变 体 构件 ( 如 “英语 显示 器 提示 ” 
或 “法 语 显示 器 提示 ”)， 都 从 抽象 “显示 器 提示 ”( Display Prompt ) 构件 中 继承 了 构件 接口 
并 各 自 实现 了 不 同 语言 版 本 的 功能 。 
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«interface» 
\DisplayPrompt 







«variant» 


«variant» 
«output device interface: 
Customerinteraction 


«output device interface» 
Customerinteraction 





initialize (in language) 

read (in promptid, out promptText) 
addPrompt (in promptid, in 
promptText) 





LTR DisplayPrompt 





RDisplayPrompt 
IDisplayPrompt 


PDisplayPrompt 


[] 
«variant» 
«entity» 
DisplayPrompts 


С) '|DisplayPrompt 10іѕріауРготрі 










Г] PDisplayPrompt Г] PDisplayPrompt 


«variant» «default» 


«entity» «entity» 
FrenchDisplayPrompts EnglishDisplayPrompts 


图 19-7 插 拨 兼容 的 变 体 构件 设计 


一 个 构件 很 有 可 能 以 不 同 的 方式 与 不 同 的 构件 连接 ， 比 如 ， 在 某 种 情况 下 它 需要 与 一 个 
构件 交互 ， 而 在 另 一 种 情况 下 ， 它 需要 与 两 个 不 同 的 构件 交互 。 这 种 灵活 性 有 助 于 软件 体系 
结构 的 演化 。 当 插 拔 兼容 的 构件 不 可 行 时 ， 构 件 接口 继承 则 是 另 一 个 可 用 的 构件 设计 方法 。 
考虑 这 样 一 种 情况 ， 在 一 个 构件 体系 结构 中 ， 需 要 改动 两 个 构件 之 间 的 接口 以 提供 新 的 功能 。 
此 时 ， 提 供 接 口 的 构件 和 请 求 接口 的 构件 都 要 修改 一 一 前 者 要 实现 新 的 功能 而 后 者 则 需 请 求 
这 一 功能 。 上 述 方法 可 对 基于 构件 的 软件 体系 结构 的 开发 方法 进行 补充 。 


19.5.2 ”软件 体系 结构 模式 


软件 体系 结构 模式 ( 见 第 12 章 ) 为 软件 总 体 体 系 结构 或 者 应 用 的 高 层 设计 提供 了 框架 或 者 模 
板 。 这 些 模 式 包括 了 广泛 使 用 的 体系 结构 ， 如 客户 端 / 服务器 和 层次 结构 。 基 于 这 些 软 件 体系 结构 
模式 来 设计 软件 产品 线 的 体系 结构 不 但 有 助 于 本 身体 系 结构 的 设计 ， 也 有 益 于 体系 结构 的 演化 。 

我 们 可 以 基于 那些 易于 理解 的 软件 总 体 体系 结构 设计 出 大 部 分 软件 系统 和 产品 线 ， 例 如 ， 
可 基于 被 广泛 使 用 的 客户 端 /服务 器 软件 体系 结构 。 基 本 的 客户 端 / 服务 器 体系 结构 模式 〈 见 
第 15 章 ) 有 一 个 服务 和 多 个 客户 端 ， 然 而 ， 该 模式 也 有 着 多 个 变种 ， 如 多 客户 端 /多 服务 体 
系 结构 模式 和 代理 者 模式 ( 见 第 16 章 )。 此 外 ， 在 客户 端 /服务 模式 下 ， 随 着 客户 端 发 现 并 
调用 新 的 服务 ， 服 务 端 会 增加 那些 服务 并 进行 演化 。 而 一 些 客户 端 发 现 服务 提供 者 所 提供 的 
服务 之 后 ， 也 会 加 入 这 一 体系 结构 。 

分 层 体系 结构 模式 ( 见 第 12 章 ) 也 很 值得 考虑 ， 因 为 这 种 体系 结构 模式 拥有 对 SPL 来 
说 很 重要 的 特点 。 一 个 分 层 体 系 结构 模式 可 以 让 软件 易于 扩展 和 交互 ， 这 是 因为 在 体系 结构 
中 ， 很 容易 添加 和 移 除 依赖 于 下 层 体 系 结构 构件 服务 的 上 层 构件 。 

除了 上 述 软 件 体 系 结构 模式 外 ， 一 些 体系 结构 通信 模式 也 支持 演化 。 在 SPL 中 ， 很 希望 
能 在 构件 间 解 耦 。 代 理 者 模式 、 发 现 模式 以 及 订阅 /通知 模式 都 具有 解 耦 特性 。 以 代理 者 模 
式 为 例 ( 见 第 16 章 )， 服 务 端 在 代理 者 中 注册 服务 ， 由 此 ， 客 户 端 可 以 发 现 新 的 服务 ; 这 样 ， 
产品 线 可 以 方便 地 添加 新 的 客户 端 和 服务 。 并 且 ， 一 个 新 版 本 的 服务 可 方便 地 替换 原 有 版 本 ， 
并 在 代理 者 注册 自己 。 而 后 ， 通 过 代理 者 与 该 服务 通信 的 客户 端 便 可 自动 使 用 新 版 本 的 服务 。 
订阅 /通知 模式 ( 见 第 17 章 ) 也 能 将 消息 的 原 有 发 送 者 与 消息 接收 者 解 耦 。 


196 总结 
本 章 介 绍 了 如 何 设计 SPL 的 体系 结构 ， 描 述 了 如 何 对 用 例 建 模 、 静 态 建 模 、 动 态 交互 建 
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模 、 动 态 状态 机 建 模 和 设计 建 模 进 行 扩 展 ， 并 把 它们 应 用 到 SPL 中 。 本 章 也 说 明了 特征 建 模 
是 来 关联 需求 可 变性 和 SPL 体系 结构 可 变性 的 统一 模型 。 关 于 这 一 话题 的 更 多 内 容 ， 可 以 参 
见 作者 关于 如 何 使 用 UML 设计 建 模 的 著作 (Gomaa 2005a)。 


练习 
选择 题 ( 每 道 题 选择 一 个 答案 ) 


1. 什么 是 软件 产品 线 (SPL ) ? 
(а) 有 着 共性 构件 和 可 变 构 件 的 一 组 软件 系统 (6) 一 条 装配 线 


(с) 一 组 完全 相同 的 系统 (4) 一 个 公司 销售 的 多 个 软件 产品 

2. 什么 是 可 选用 例 ? 

(а) 有 着 可 选 步骤 的 用 例 (b ) 一 个 可 以 不 用 开发 的 用 例 

(с) 部 分 产品 线 成 员 所 需 的 用 例 (d) 可 在 一 个 SPL 成 员 中 替换 用 例 的 用 例 
3. 什么 是 用 例 可 变 点 ? 

(a ) 一 个 可 变 用 例 (b) 一 个 用 例 中 可 发 生变 化 的 位 置 

(с) 一 个 可 替换 用 例 (а) 一 个 用 例 中 可 替换 路 径 开 始 的 位 置 


4. 什么 是 SPL 特征 ? 
(а) 一 个 或 者 多 个 SPL 成 员 提 供 的 需求 或 者 特性 (b) 一 个 市 场 需求 


(с) 一 个 SPL 提供 的 类 (d) 一 个 SPL 用 例 

5. 什么 是 SPL 特征 组 ? 

(a) 一 组 特征 355 
(b) 一 个 SPL 成 员 中 有 着 特定 使 用 约束 的 一 组 特征 

(с) 一 组 互 斥 特征 


(а) 一 个 SPL 成 员 中 有 着 特定 使 用 约束 的 一 组 可 选 特征 
6. 什么 是 SPL 中 的 核心 类 ? 


(a) SPL 中 的 实体 类 (b) 储存 必要 数据 的 SPL 类 
(с) 所 有 SPL 成 员 都 需要 的 类 (d) SPL 的 外 部 类 

7. 用 来 建 模 SPL 类 的 两 种 构造 型 是 ? 

(а) 核心 和 可 选 构造 型 (b) 可 选 和 变 体 的 构造 型 
(с) 共性 和 变 体 构造 型 (d) 复 用 和 应 用 角色 构造 型 
8. 如 何在 SPL 状态 机 中 使 用 特征 条 件 ? 

(a) 用 作 控 制 条 件 (b) 作为 真 或 假 的 条 件 


(с) 用 于 确定 某 特征 在 状态 机 中 是 否 被 选择 (а) 用 于 允许 状态 机 继承 
9. 什么 是 SPL 的 核心 系统 ? 

(a) 一 个 只 由 核心 类 组 成 的 SPL 成 员 

(b) 一 个 由 核心 类 和 一 些 可 能 的 默认 类 组 成 的 SPL 成 员 

(с) 一 个 由 核心 类 和 一 些 可 能 的 可 选 类 组 成 的 SPL 成 员 

(а) 一 个 由 核心 类 和 一 些 可 能 的 实体 类 组 成 的 SPL 成 员 
10. SPL 软件 体系 结构 描述 了 什么 ? 

(a) 一 组 建筑 内 的 软件 (b) 客户 端 /服务 器 产品 家 族 的 结构 

(с) 软件 产品 线 的 总 体 结构 (4) 软件 产品 线 的 类 和 它们 之 间 的 关系 356 
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软件 质量 属性 (Bass, Clements, and Kazman 2003 ) 指 软件 的 非 功能 性 需求 ， 能 深刻 影 
响 软件 产品 质量 。 这 些 属 性 中 很 多 可 以 在 软件 体系 结构 开发 时 被 阐述 和 评价 。 软 件 质量 属性 
包括 可 维护 性 、 可 修改 性 、 可 测试 性 、 可 追踪 性 、 可 扩展 性 、 可 复 用 性 、 性 能 、 可 用 性 和 安 
全 性 。4.6 节 给 出 了 软件 质量 属性 的 介绍 。 本 节 将 描述 上 述 每 个 属性 ， 并 讨论 它们 是 如 何 被 
COMET 设计 方法 支持 的 。 

有 些 软件 质量 属性 也 是 系统 质量 属性 ， 因 为 它们 同时 需要 硬件 和 软件 来 达到 高 质量 。 这 
些 质量 属性 的 例子 有 : 性 能 、 可 用 性 和 安全 性 。 另 一 些 软件 质量 属性 是 纯粹 的 软件 性 质 ， 因 
为 它们 完全 依靠 软件 的 质量 。 这 些 质 量 属性 的 例子 有 : 可 维护 性 、 可 修改 性 、 可 测试 性 和 可 
追踪 性 。 


20.1 可 维护 性 


可 维护 性 是 软件 在 部 署 后 能 被 更 改 的 程度 。 软 件 可 能 由 于 以 下 原因 需要 被 修改 : 

© 修复 残留 的 错误 。 这 些 是 在 部 署 前 的 软件 测试 期 间 未 被 检测 出 来 的 错误 。 

e 解决 性 能 问题 。 性 能 问题 可 能 只 有 在 软件 应 用 被 部 署 和 现场 操作 后 才 会 显现 出 来 。 

° 软件 需求 的 变更 。 软 件 变更 最 主要 的 原因 是 软件 需求 的 变更 。 

在 很 多 情况 下 ， 软 件 维护 实际 上 是 对 软件 演化 的 不 恰当 称呼 。 特 别 地 ， 软 件 需求 中 未 预 
期 的 变更 需要 对 软件 产生 可 能 是 很 大 的 修改 。 为 了 应 对 将 来 的 演化 ， 软 件 就 要 为 变化 和 适应 
性 而 设计 。 质 量 必 须 构建 到 原始 产品 中 ， 以 使 之 可 维护 ， 这 意味 着 采用 一 个 好 的 软件 开发 过 
程 以 及 为 该 产品 提供 全 面 的 文档 。 在 软件 被 修改 时 ， 文 档 要 保持 最 新 。 要 提供 设计 原理 ， 以 
解释 已 做 出 的 设计 决策 。 和 否则， 维护 人 员 除 了 对 着 没有 文档 、 结 构 或 许 很 不 合理 的 代码 工作 
之 外 别 无 选择 。 

COMET 提供 了 全 面 的 设计 文档 以 支持 可 维护 性 。 通 过 使 用 构造 型 ， 允 许 在 设计 中 包含 
设计 构造 决策 ， 因 此 ， 设 计 决 策 实际 上 在 设计 中 被 捕获 。 采 用 基于 用 例 的 开发 方法 ， 一 个 需 
求 变 更 的 影响 可 以 从 用 例 追 踪 到 软件 设计 和 实现 。 另 外 ，COMET 对 可 修改 性 和 可 测试 性 的 
支持 极 大 地 帮助 了 产品 的 可 维护 性 。 

作为 COMET 如 何 提供 可 维护 性 的 例子 ， 考 虑 这 样 一 个 需求 变更 : 要 求 “银行 系统 ”在 
南美 、 欧 洲 和 非洲 都 可 用 。 特 别 地 ， 这 要 求 提 示 信 息 能 用 不 同 的 语言 显示 。 每 个 向 客户 提供 
提示 信息 的 用 例 都 被 这 个 变更 潜在 地 影响 了 。 对 设计 的 分 析 显 示 唯 一 连接 到 客户 的 对 象 是 
“客户 交互 ”( Customer Interaction )。 一 个 好 的 设计 方案 会 试图 把 设计 变更 限制 到 最 小 。 一 个 
可 以 达到 这 个 目的 的 变更 是 所 有 被 “ATM 控制 ”对 象 发 送 到 “客户 交互 ”对 象 的 提示 都 具有 
一 个 提示 ID， 用 此 来 代替 提示 的 文本 内 容 。 如 果 “ 客 户 交 互 ” 已 经 将 提示 消息 硬 编码 了 ， 则 
这 些 提 示 需 要 被 移 除 并 放置 在 一 个 提示 表 中 。 这 个 提示 表 用 一 列表 示 提 示 ID ， 用 另外 一 列表 
示 相 应 的 提示 文本 。 只 要 给 出 提示 ID， 一 个 简单 的 表 查 询 就 能 返回 提示 的 文本 。 在 系统 初始 
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化 时 ， 所 需 语言 的 提示 表 会 被 加 载 。 默 认 的 提示 表 是 英文 的 。 对 于 南美 市 场 (除了 巴西 ) 和 
西班牙 市 场 ， 西 班 牙 语 提 示 表 会 被 加 载 。 对 于 法 国 、 岁 北 克 和 西非 大 部 分 地 区 ， 法 语 提 示 表 
将 在 初始 化 时 被 加 载 。 带 有 中 文 提示 的 提示 表 的 例子 如 表 20-1 所 示 。 


表 20-1 全 球 系统 中 可 维护 性 示例 : 带 有 特定 语言 提示 的 提示 表 


提示 ID 提示 文本 
Get-PIN 请 输入 您 的 密码 : 
Invalid-PIN-Prompt 密码 无 效 。 请 重新 输入 您 的 密码 : 
Display-Confiscate 您 的 请 求 出 现 了 问题 。 您 的 卡 被 收回 。 请 联系 您 的 发 卡 行 。 
20.2 可 修改 性 


可 修改 性 是 软件 在 最 初 的 部 署 期 间 及 之 后 能 够 被 修改 的 程度 。 由 带 有 和 良 定 义 接 口 的 模块 
组 成 的 模块 化 设计 是 十 分 重要 的 。Parnas 主张 基于 信息 隐藏 概念 为 变更 而 设计 ， 其 中 变更 是 
通过 每 个 隐藏 了 一 个 可 以 独立 于 软件 的 其 他 部 分 而 变更 的 秘密 的 信息 隐藏 模块 来 预期 和 管理 
的 。 信 息 隐藏 是 基础 的 设计 概念 ( 见 第 4 章 )， 它 形成 了 面向 对 象 设 计 的 基础 。 

COMET 通过 在 类 和 构件 级 别 为 信息 隐藏 提供 支持 以 及 在 子 系统 级 别 为 关注 点 分 离 提 供 
支持 的 方式 来 支持 可 修改 性 。 如 下 的 决策 对 提高 可 修改 性 有 帮助 :( a ) 将 每 个 有 限 状 态 机 封 
装 在 一 个 单独 的 状态 机 类 中 ，(b ) 将 每 个 连接 到 单独 的 外 部 设备 、 系 统 或 用 户 的 接口 封装 到 
单独 的 边界 类 中 ,(c ) 将 每 个 单独 的 数据 结构 封装 在 一 个 单独 的 数据 抽象 类 中 。 在 体系 结构 
级 别 上 ，COMET 基于 构件 的 软件 体系 结构 设计 方法 令 构 件 的 设计 在 软件 部 署 时 期 可 以 被 部 
署 在 不 同 的 分 布 式 结 点 上 ， 使 得 相同 的 体系 结构 可 以 部 署 到 很 多 不 同 的 配置 上 ， 以 支持 不 同 
的 应 用 实例 。 

继续 提示 表 的 例子 。 使 用 COMET， 提 示 表 的 设计 会 影响 静态 和 动态 模型 。 首 先 ， 提 示 
表 会 被 封装 到 一 个 提示 类 中 。 因 为 要 求 能 支持 不 同 语言 ， 所 以 一 个 好 的 方法 是 设计 一 个 名 为 
“显示 器 提示 ”( Display Prompts) 的 超 类 ， 并 为 每 种 语言 设计 子 类 。 最 初 的 需求 是 英语 (R 
认 )、 法 语 、 意 大 利 语 、 西 班 牙 语 和 德语 提示 ( 图 20-1); 然而 ， 设 计 应 该 允许 扩展 到 其 他 语 
言 。 这 个 问题 的 解决 方案 是 把 Display Prompts 类 设计 为 一 个 具有 公共 接口 的 抽象 类 ， 这 个 公 
共 接 口 由 一 个 读 操作 ( 从 提示 表 读 取 提 示 ) 和 一 个 更 新 操作 (更 新 提示 表 并 添加 新 提示 ) 构 
成 。 特 定语 言 的 提示 子 类 会 继承 这 个 不 被 修改 的 接口 ， 然 后 提供 特定 语言 的 实现 。 这 个 问题 
的 另 一 个 解决 方案 是 使 用 软件 产品 线 的 概念 〈 见 第 19 章 )。 


«entity» 
DisplayPrompts 
ZN 
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English French Spanish German 
DisplayPrompts DisplayPrompts DisplayPrompts DisplayPrompts 


图 20-1 可 修改 性 示例 : 抽象 Display Prompts 超 类 和 特定 语言 子 类 359 


274 ТЕТ КРКА 


20.3 可 测试 性 


可 测试 性 是 软件 能 够 被 测试 的 程度 。 在 软件 生存 周期 的 早期 建立 一 个 软件 测试 计划 并 且 
与 软件 开发 并 行 地 计划 开发 测试 用 例 是 很 重要 的 。 下 面 的 段落 描述 了 不 同 阶段 的 软件 测试 怎 
样 和 COMET 方法 整合 在 一 起 。 软 件 测试 的 一 个 全 面 描述 由 Ammann and Offutt( 2008 ) 给 出 。 

在 需求 阶段 ， 开 发 功能 性 RA) 测试 用 例 是 必要 的 ， 这 些 测试 用 例 可 以 从 用 例 模型 
(特别 是 用 例 描 述 ) 中 开发 出 来 。 因 为 用 例 描述 描述 了 用 户 和 系统 的 交互 顺序 ， 因 此 它们 描述 
了 测试 用 例 需要 捕获 的 用 户 输入 和 预期 的 系统 输出 。 需 要 为 每 个 用 例 场景 开发 一 个 测试 用 例 。 
用 例 的 主 序列 要 一 个 测试 用 例 ， 用 例 的 每 个 可 替换 序列 要 一 个 测试 用 例 。 用 这 种 方法 ， 可 以 
开发 一 个 测试 套件 来 测试 系统 的 功能 性 需求 。 

在 软件 体系 结构 设计 阶段 ， 开 发 集成 测试 用 例 是 必要 的 ， 以 此 测试 相互 通信 的 构件 之 间 的 
接口 。 交 互 模型 (Al) 显示 了 对 象 之 间 相 互通 信 的 顺序 以 及 相互 传递 的 消息 ， 一 种 称 作 基于 场景 
测试 的 测试 方法 可 用 于 测试 使 用 对 应 于 交互 模型 (图 ) 中 的 用 例 场 景 的 实现 的 场景 顺序 的 软件 。 

在 开发 每 个 构件 的 内 部 算法 的 详细 设计 和 编码 阶段 ， 可 以 开发 白 盒 测试 用 例 ， 使 用 众 所 
周知 的 覆盖 标准 (如 执行 每 一 行 代码 和 每 个 判断 的 结果 ) 来 测试 构件 内 部 。 通 过 这 种 方式 ， 
可 以 开发 出 单元 测试 用 例 来 测试 独立 的 单元 ( 例如 构件 )。 

基于 “银行 系统 ”中 “验证 PIN 码 ” 用 例 给 出 一 个 黑 盒 测 试用 例 的 例子 ， 这 个 黑 盒 测 试 
用 例 由 插入 卡 、 提 示 输 入 PIN 码 和 验证 卡 ID/PIN 构成 。 最 开始 ， 可 以 开发 一 个 测试 桩 对 象 ， 
来 模拟 读 卡 器 并 提供 从 模拟 卡 读 出 的 输入 : 卡 ID， 开 始 日 期 和 截止 日 期 。 然 后 ， 系 统 提 示 
输入 PIN 码 ( 另 一 个 测试 桩 模拟 用 户 输入 PIN 码 )， 接 着 向 “银行 服务 ” 子 系统 (或 者 开发 
过 程 中 的 服务 器 桩 ) 发 送 卡 和 PIN 的 信息 。 可 以 用 “ 借 记 卡 ” 实 体 类 实现 为 一 个 关系 表 的 方 
式 来 建立 起 一 个 测试 环境 。 这 会 允许 用 例 的 主 序列 ( 有 效 PIN ) 以 及 所 有 可 替换 序列 ( 无效 
PIN、 三 次 无 效 PIN、 卡 已 丢失 或 被 次 等 ) 被 测试 。 


20.4 可 追踪 性 


可 追踪 性 是 产品 的 每 个 阶段 能 被 追踪 到 之 前 阶段 的 程度 。 需 求 可 追踪 性 用 于 确保 每 个 软 
件 需求 都 被 设计 和 实现 了 。 每 个 需求 都 被 追踪 到 软件 的 体系 结构 和 已 实现 的 代码 模块 。 在 软 
件 体 系 结构 评审 期 间 ， 需 求 追踪 表 是 一 个 有 用 的 工具 ， 用 来 分 析 软 件 体 系 结构 是 否 已 经 解决 
了 所 有 的 软件 需求 。 

在 软件 开发 方法 中 建立 可 追踪 性 是 有 可 能 的 ，COMET 方法 就 是 这 样 。COMET 是 一 个 基于 
用 例 的 开发 方法 ， 从 用 例 开 始 ， 确 定 实现 每 个 用 例 所 需要 的 对 象 。 软 件 需求 中 描述 的 每 个 用 例 被 
细 化 到 一 个 基于 用 例 的 交互 图 中 ， 这 个 交互 图 描述 了 对 象 通信 的 顺序 ， 从 用 例 中 描述 的 外 部 输入 
开始 直到 系统 和 输出。 这些 交互 图 被 集成 为 软件 体系 结构 。 这 意味 着 每 个 需求 可 以 从 用 例 追 踪 到 软 
件 设 计 与 实现 。 因 此 ， 需 求 变更 造成 的 影响 可 以 通过 跟随 从 需求 到 设计 的 追踪 轨迹 来 确定 。 

一 个 可 追踪 性 的 例子 是 考虑 “银行 系统 ”中 “验证 PIN 码 ” 用 例 。 在 动态 模型 中 ， 它 
是 由 “验证 PIN 码 ” 通 信和 图 实现 的 。 由 于 提示 语言 这 一 需求 的 增加 而 必需 的 变更 可 以 通过 影 
响 分 析 来 确定 ， 这 个 影响 分 析 揭 示 了 在 显示 提示 之 前 提示 对 象 需要 被 “客户 交互 ”对 象 访问 
( 如 图 20-2 所 示 )。 图 20-2a 显示 了 “客户 交互 ”直接 输出 到 显示 器 的 原始 设计 ， 而 图 20-2b 
显示 了 “客户 交互 ”在 输出 到 显示 需 之 前 从 “显示 器 提示 ”对 象 读 取 提 示 文 本 这 一 修改 的 设 
计 。 这 个 问题 的 另 一 种 解决 方案 是 使 用 软件 产品 线 的 概念 ， 如 第 19 章 所 述 。 
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20.5 可 扩展 性 


可 扩展 性 是 系统 在 其 最 初 部 署 之 后 能 够 生长 的 程度 。 可 扩展 性 要 考虑 系统 因素 和 软件 因 
素 。 从 系统 的 角度 来 看 ， 有 通过 添加 硬件 来 增加 系统 容量 的 问题 。 在 一 个 集中 式 的 系统 中 ， 
可 扩展 性 的 范围 是 有 限 的 ， 例 如 添加 更 多 内 存 、 硬 盘 或 者 额外 的 CPU。 一 个 分 布 式 系统 通过 
向 配置 添加 更 多 结 点 来 提供 更 大 范围 的 可 扩展 性 。 

从 软件 的 角度 来 看 ， 应 用 需要 以 一 种 使 它 能 够 生长 的 方式 设计 。 基 于 构件 的 分 布 式 软件 
体系 结构 比 起 一 个 集中 式 的 设计 更 具有 扩展 的 能 力 。 构 件 被 这 样 设计 : 使 得 每 个 构件 的 多 个 
实例 能 部 署 在 分 布 式 配置 中 的 不 同 结 点 上 。 一 个 支持 多 电梯 和 多 楼 层 的 电梯 控制 系统 能 拥有 
一 个 电梯 构件 和 一 个 楼 层 构件 ， 使 得 每 个 电梯 和 每 个 楼 层 各 存在 一 个 实例 。 这 样 的 软件 体系 
结构 能 被 部 署 到 一 个 小 建筑 、 大 宾馆 或 摩天 大 厦 中 执行 。 面 向 服务 的 体系 结构 能 通过 添加 更 
多 服务 或 现 有 服务 的 附加 实例 来 扩展 。 新 的 客户 端 按 需 添加 到 系统 中 。 客 户 端 能 发 现 新 的 服 
务 并 且 利 用 它们 的 供给 。 

COMET 通过 提供 设计 基于 构件 的 分 布 式 软件 体系 结构 和 面向 服务 的 体系 结构 来 解决 可 
扩展 性 ， 这 两 种 体系 结构 在 部 署 后 能 被 扩展 。 例 如 ， 应 急 监控 系统 能 通过 添加 更 多 远程 传 感 
器 来 扩展 ， 可 以 以 额外 的 传感器 或 额外 的 外 部 系统 的 形式 ， 也 可 以 是 “监控 数据 服务 ”和 
“警报 服务 ”的 更 多 实例 。 这 种 扩展 还 可 能 是 添加 更 多 的 服务 ， 如 “报告 服务 ”( Reporting 
Service) 和 “气象 服务 ”( Weather Service )， 以 及 这 些 服务 的 更 多 实例 。 应 急 监 控 系 统 的 部 署 
图 (图 20-3 ) 显示 了 基于 构件 的 软件 体系 结构 是 怎样 被 扩展 的 。 
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Al 20-3 应急 监控 系统 的 扩展 


“在 线 购 物 系 统 ” 可 以 通过 添加 更 多 的 服务 来 扩展 。 目 录 服 务 可 以 被 扩展 以 支持 多 个 经 销 
商 〈 供 应 商 )。 接 着 ， 这 些 不 同 的 供应 商会 被 添加 到 系统 。 每 个 供应 商 的 操作 可 能 很 不 一 样 ， 
但 都 需要 符合 面向 服务 体系 结构 所 规定 的 接口 。 


20.6 ASA 


软件 可 复 用 性 是 软件 能 够 被 复 用 的 程度 。 在 传统 的 软件 复 用 中 开发 了 可 复 用 代码 构件 的 
程序 库 ， 例 如 统计 子 例 程 程序 库 。 这 种 方法 需要 建立 一 个 可 复 用 构件 的 程序 库 ， 以 及 一 个 索 
引 、 定 位 、 区 分 相似 构件 的 方法 ( Prieto-Diaz and Freeman 1987 )。 这 种 方法 的 问题 包括 如 何 
管理 这 样 的 复 用 库 可 能 包含 的 大 量 构件 ， 以 及 如 何 区 分 相似 但 不 完全 相同 的 构件 。 

当 一 个 新 设计 被 开发 时 ， 设 计 者 有 责任 设计 软件 体系 结构 ， 即 程序 的 整体 结构 和 整体 的 
控制 流 。 在 库 中 定位 和 选择 了 一 个 可 复 用 的 构件 之 后 ， 设 计 者 就 必须 确定 这 个 构件 如 何 融 人 
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新 的 体系 结构 。 

相对 于 复 用 单个 构件 ， 更 好 的 方法 是 复 用 由 构件 及 其 相互 连接 构成 的 整个 设计 或 子 系统 。 
这 意味 着 复 用 应 用 的 控制 结构 。 体 系 结构 的 复 用 比 构件 复 用 具有 更 大 的 潜力 ， 因 为 它 是 大 粒 
度 的 复 用 ， 关 注 于 对 需求 和 设计 的 复 用 。 

体系 结构 复 用 最 有 前 途 的 方法 是 开发 软件 产品 线 体系 结构 ( Gomaa 2005a )， 软 件 产品 
线 体 系 结构 明确 地 捕获 了 组 成 产品 线 的 系统 家 族 的 共性 和 可 变性 。 软 件 产品 线 体 系 结构 
一 个 产品 家 族 的 体系 结构 一 一 需要 描述 该 家 族 中 的 共性 和 可 变性 。 依 赖 于 所 使 用 的 开发 方法 
( 函数 式 的 或 面向 对 象 的 )， 产 品 线 共性 以 公共 模块 、 类 或 构件 的 方式 来 描述 ， 产 品 线 可 变性 
以 可 选 或 变 体 模块 、 类 或 构件 来 描述 。 

应 用 工程 这 个 术语 是 指 剪裁 和 配置 产品 家 族 体 系 结构 和 构件 的 过 程 ， 以 创建 一 个 作为 该 
产品 家 族 成 员 的 特定 应 用 。 

PLUS 是 COMET 的 一 个 扩展 ， 用 来 设计 软件 产品 线 体系 结构 。PLUS 的 概述 在 第 19 章 
中 给 出 ，Gomaa (2005a) 给 出 了 完整 而 详细 的 描述 。 第 19 章 中 描述 了 一 个 用 软件 产品 线 方 
法 设计 “显示 器 提示 ” 超 类 和 特定 语言 子 类 的 例子 。 








20.7 ”性 能 


性 能 也 是 很 多 系统 中 的 一 个 重要 的 考虑 因素 。 在 设计 时 对 系统 进行 性 能 建 模 对 确定 系统 
是 否 满足 其 性 能 目标 〈 如 吞吐 量 和 响应 时 间 ) 是 很 重要 的 。 性 能 建 模 方法 有 队列 建 模 (Gomaa 
and Menasce 2001 ; Menasce and Gomaa 2000) 和 仿真 建 模 。 性 能 建 模 在 实时 系统 中 尤为 重要 ， 
未 能 满足 最 后 期 限 要 求 可 能 是 灾难 性 的 。 实 时 调度 结合 事件 序列 建 模 是 对 执行 在 给 定 硬件 配 
置 上 的 实时 设计 进行 建 模 的 一 种 方法 。 

在 COMET/RT 中 ， 软 件 设计 的 性 能 分 析 通 过 实时 调度 理论 实现 。 实 时 调度 是 一 个 特别 适 
合 于 有 必须 满足 的 最 后 期 限 的 硬 实时 系统 的 方法 。 用 这 种 方法 来 分 析 实 时 设计 ， 以 确定 它 是 
否 满足 最 后 期 限 要 求 。 分 析 设 计 性 能 的 另 一 种 方法 是 用 事件 时 序 分 析 并 将 其 与 实时 调度 理论 
集成 。 除 了 考虑 系统 在 对 象 间 通 信和 上 下 文 转换 ( Gomaa 2000) 上 的 开销 以 外 ， 事件 时 序 分 
析 还 用 来 分 析 通 信任 务 的 场景 并 且 用 计时 参数 对 每 个 参与 的 任务 进行 标记 。 

考虑 第 21 章 所 描述 的 “银行 系统 ”， 画 出 部 署 图 如 图 20-4 所 示 。 其 中 ,“ 银 行 服务 ” 
(Banking Service ) 执行 在 一 个 服务 器 结 点 上 。 银 行 服务 的 性 能 评测 会 包括 对 ATM 客户 端 请 求 






:BankingService 
{1 server node} 








мы | 

nn eee re 
: ATMClient : ATMClient : ATMClient 

{1 node per ATM} {1 node per ATM} {1 node per ATM} 


图 20-4 “银行 系统 ”的 不 同 硬件 配置 的 实验 
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的 响应 时 间 和 以 每 秒 交 易 数 表示 的 交易 处 理 率 。 可 以 开发 一 个 队列 模型 来 评 佑 “银行 系统 ” 
在 不 同 ATM 交易 负载 下 的 性 能 ， 据 此 来 计划 服务 器 所 需 的 从 CPU、 主 存 、 辅 助 存储 以 及 所 
需 网 络 带宽 等 方面 来 看 的 容量 。 基 于 对 于 客户 和 账户 记录 数量 和 大 小 的 估计 ， 也 可 以 预 估 出 
所 需 的 磁盘 空间 。 可 以 采用 不 同 的 硬件 配置 (包括 单 处 理 器 、 双 处 理 器 配置 ) 来 进行 性 能 比 
较 ， 也 可 以 采用 可 替换 的 软件 设计 和 硬件 配置 进行 性 能 比较 。 例 如 ， 将 一 个 在 单个 结 点 上 的 
顺序 “银行 服务 ”和 一 个 在 两 个 结 点 上 的 并 发 “银行 服务 ”进行 比较 。 


20.8 安全 性 


安全 性 是 很 多 系统 中 的 一 个 重要 考虑 因素 。 分 布 式 应 用 系统 ( 例如 电子 商务 和 银行 系统 ) 
中 存在 很 多 潜在 威胁 。 有 不 少 阐述 计算 机 、 信 息 和 网 络 安全 问题 的 教材 ， 包 括 Bishop (2004) 
和 Pfleeger (2006)。 一 些 潜 在 的 威胁 如 下 : 
e 系统 穿 透 。 未 经 授权 的 人 试图 获得 访问 应 用 系统 的 权限 并 执行 未 经 授权 的 事务 。 
ө 违反 授权 。 获 得 授权 的 人 误 用 或 滥用 应 用 系统 。 
о 保密 信息 披露 。 机 密 信息 ( 如 卡号 和 银行 账户 ) 被 透露 给 未 经 授权 的 人 。 
© 完整 性 破坏 。 未 经 授权 的 人 更 改 了 数据 库 中 的 应 用 数据 或 通信 数据 。 
e 抵赖 。 执 行 了 某 些 事务 或 者 通信 活动 的 人 事后 错误 地 和 否认 这 些 事务 或 者 活动 的 发 生 。 
e 拒绝 服务 。 对 应 用 系统 的 合法 访问 被 恶意 干扰 。 
COMET 扩展 了 用 例 的 描述 ， 以 允许 描述 非 功能 性 需求 ， 包 括 安 全 性 需求 。 第 6 章 中 给 
出 了 一 个 扩展 用 例 以 允许 非 功能 性 需求 的 例子 。 
下 面 的 列表 描述 了 如 何 解 决 “ 银 行 系统 ”中 的 这 些 潜在 威胁 ( 注意 不 是 所 有 威胁 都 用 纯 
软件 的 方法 解决 ): 
e 系统 穿 透 。 这 个 问题 的 解决 方案 是 在 消息 源 对 消息 加 密 ， 特 别 是 起 始 于 АТМ 客户 端 
的 事务 和 银行 服务 发 送 的 响应 ， 然 后 在 目的 地 解密 消息 。 
e 违反 授权 。 获 得 授权 使 用 应 用 系统 的 人 误 用 或 滥用 系统 。 需 要 维护 该 系统 的 所 有 访问 
日 志 ， 这 样 就 能 追踪 到 误 用 或 者 滥用 的 情况 ， 使 得 任何 滥用 都 能 被 纠正 。 
о 保密 信息 披露 。 需 要 用 访问 控制 方法 保护 机 密 信息 ， 如 信用 卡号 和 银行 账户 ， 只 允许 
带 有 正确 权限 的 用 户 访问 数据 。 
e 完整 性 破坏 。 需 要 强制 执行 访问 控制 ， 以 确保 未 经 授权 的 人 无 法 更 改 数据 库 中 的 应 用 
数据 或 通信 数据 。 
e 抵赖 。 需 要 维护 一 个 记录 所 有 事务 的 日 志 ， 使 得 通过 分 析 日 志 能 验证 声称 这 些 事务 或 
活动 没 发 生 过 的 声明 。 
e 拒绝 服务 。 必 须要 有 人 侵 检 测 能 力 ， 使 得 系统 能 检测 未 经 授权 的 人 侵 并 采取 行动 拒绝 
它们 。 


20.9 可 用 性 


可 用 性 阐述 了 系统 失效 及 其 对 用 户 和 其 他 系统 的 影响 。 总 有 一 些 时 候 由 于 预定 的 系统 维 
护 使 得 系统 对 用 户 是 不 可 用 的 ; 这 种 计划 中 的 不 可 用 性 通常 不 算 在 可 用 性 的 测量 中 。 然 而 ， 
作为 系统 失效 必然 结果 的 计划 外 系统 维护 总 是 被 算 在 内 的 。 某 些 系统 需要 全 时 运行 ; 在 一 个 
控制 飞机 或 飞船 的 系统 上 发 生 系统 失效 的 影响 将 是 灾难 性 的 。 
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容错 系统 中 建立 了 恢复 机 制 ， 以 便 系统 能 从 失效 中 自动 恢复 。 然 而 ， 这 些 系统 通常 是 非 
常 昂贵 的 ， 需要 诸如 三 倍 元 余 和 投票 系统 这 样 的 能 力 。 还 有 其 他 一 些 不 太 昂贵 的 解决 方案 , 例 
如 一 个 热 备 份 ， 它 是 一 台 在 系统 失效 之 后 很 短 时 间 内 就 准备 就 绪 的 机 器 。 热 备份 可 以 在 一 个 客 
户 端 / 服 务 器 系统 提供 给 服务 器 。 可 以 设计 一 个 没有 单 点 失效 的 分 布 式 系 统 ， 这 样 一 个 结 点 失 
效 只 会 导致 减少 服务 ， 伴 随 着 系统 在 一 个 降级 的 模式 下 运行 。 这 通常 比 没有 任何 服务 要 好 。 

从 软件 设计 的 角度 ， 支 持 可 用 性 需要 系统 设计 没有 单 点 失效 。COMET 通过 提供 一 种 设 
计 基 于 构件 的 分 布 式 软件 体系 结构 的 方法 支持 可 用 性 。 这 种 体系 结构 能 部 署 到 带 有 分 布 式 控 
制 、 数 据 和 服务 的 多 个 结 点 上 ， 使 得 即使 单个 结 点 停机 时 系统 也 不 会 失效 而 且 能 运行 在 一 种 
降级 模式 下 。 

作为 案例 研究 的 示例 ， 热 备份 可 以 用 于 “银行 系统 ”"”， 即 一 个 集中 式 的 客户 端 /服务 器 系 
统 ， 其 中 银行 服务 器 是 失效 的 单 点 ( 图 20-4 )。 热 备份 是 一 个 备份 服务 器 ， 如 果 主 服务 器 宕 机 
它 可 以 迅速 部 署 。 一 个 没有 单 硬件 失效 点 的 分 布 式 系统 的 示例 是 应 急 监 控 系统 ， 其 中 用 户 IO 
构件 、 监 控 和 报警 服务 以 及 操作 员 交 互 构件 都 能 被 复制 。 每 个 客户 端 构 件 都 有 多 个 实例 ， 因 
此 如 果 一 个 构件 坏 了 ， 系 统 仍 然 可 以 运行 。 服 务 能 被 复制 ,这样 “ 监 控 数据 服务 ”和 “警报 
服务 ”就 有 多 个 实例 。 图 20-5 的 部 署 图 阐明 了 这 个 情况 。 假 定 使 用 的 是 因特网 ， 其 中 可 能 会 
有 局 部 失效 但 不 会 全 局 失效 ， 因 此 单个 结 点 甚至 区 域 性 子 网 可 能 有 时 是 不 可 用 的 ， 但 是 其 他 
区 域 仍 然 在 运作 中 。 


Remote System 
Proxy 
{1 node per remote 


system} 
















оде per 


Monitoring Sensor 
Component 

п 

monitoring location} 


«wide area network» {1 node per 


operator} 















a 
Operator 
Presentation 


oa Data 
Alarm Service 
{1 node per {1 eae per 
region} region} 


图 20-5 没有 单一 硬件 失效 点 的 系统 示例 


20.10 总 结 


本 章 论述 了 软件 体系 结构 的 软件 质量 属性 及 它们 是 如 何 用 于 评价 软件 体系 结构 的 质量 的 。 
本 章 描述 的 软件 质量 属性 包括 可 维护 性 、 可 修改 性 、 可 测试 性 、 可 追踪 性 、 可 扩展 性 、 可 复 


用 性 、 人 性 能 、 可 用 性 和 安全 性 。 更 详细 的 关于 软件 质量 属性 的 描述 在 Bass, Clements, and 
Kazman( 2003 ) 和 Taylor, Medvidovic, and Dashofy (2009) 中 。 


练习 


选择 题 〈 每 道 题 选 择 一 个 答案 ) 

1. 软件 质量 属性 阐述 了 什么 ? 
(a) 软件 功能 性 需求 (b) 软件 非 功能 性 需求 
(с) 软件 性 能 需求 (а) 软件 可 用 性 需求 
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2. 什么 是 可 维护 性 ? 
(а) 软件 在 部 署 前 能 够 被 变更 的 程度 
(с) 软件 在 开发 期 间 能 够 被 变更 的 程度 
3. 什么 是 可 修改 性 ? 
(а) 软件 在 部 署 后 能 够 被 修改 的 程度 


Cb) 软件 在 部 署 后 能 够 被 变更 的 程度 
(4) 软件 在 开发 后 能 够 被 变更 的 程度 


(b) 软件 在 最 初 的 开发 后 能 够 被 修改 的 程度 


(с) 软件 在 最 初 的 开发 期 间 和 之 后 能 够 被 修改 的 程度 


(а) 软件 在 部 署 前 能 够 被 变更 的 程度 
4. 什么 是 可 测试 性 ? 

(а) 软件 能 够 被 开发 的 程度 

(с) 软件 在 部 署 后 能 够 被 测试 的 程度 
5. 可 追踪 性 是 一 个 产品 什么 的 程度 ? 

(a) 能 被 追踪 回 之 前 阶段 的 产品 

(с) 前 向 追踪 到 实现 
6. 什么 是 可 扩展 性 ? 

(a) 一 个 应 用 能 生长 的 程度 

(c) 系统 在 开发 过 程 中 能 够 生长 的 程度 
7. 什么 是 可 复 用 性 ? 

(а) 软件 实现 被 复 用 的 程度 

(с) 软件 产品 线 技术 能 被 引入 的 程度 
8. 下 列 哪 一 项 不 是 性 能 相关 的 ? 

(а) 系统 响应 时 间 

(c) 系统 可 用 性 
9. 下 列 哪 一 项 不 能 通过 安全 系统 解决 ? 

(a) 系统 穿 透 

(с) 系统 扩展 性 
10. 可 用 性 解决 了 下 列 哪个 系统 问题 ? 

(a) 拒绝 服务 
(с) 系统 吞吐 量 


(b) 软件 在 部 署 前 能 够 被 测试 的 程度 
(4) 软件 被 理解 的 程度 


(b) 追踪 回 需求 
Cd) 部 署 到 一 个 硬件 配置 


(b) 系统 在 最 初 部 署 之 后 能 够 生长 的 程度 
(d) 系统 可 以 被 扩展 的 程度 


(b ) 软件 能 够 被 复 用 的 程度 
(а) 软件 在 程序 家 族 中 公共 的 程度 


(b) 系统 吞吐 量 
(d) 系统 容量 


(b) 拒绝 服务 
(d) 系统 授权 


(b) 单 点 失效 
(d) 系统 穿 透 
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本 章 将 介绍 如 何 应 用 COMET/UML 软件 建 模 与 设计 方法 来 设计 一 个 客户 端 /服务 器 软件 
体系 结构 ( 见 第 15 章 ) : 银行 系统 。 此 外 ，ATM 客户 端的 设计 也 被 作为 设计 并 发 软件 的 一 个 
例子 ( 见 第 18 章 )， 而 银行 服务 的 设计 则 被 作为 顺序 性 面向 对 象 软件 设计 的 一 个 例子 ( 见 第 
14 章 )。 

21.1 节 介绍 本 案例 中 的 问题 。21.2 节 给 出 “银行 系统 ”的 用 例 模 型 。21.3 节 描 述 静 态 模 
型 ,覆盖 了 系统 上 下 文 以 及 实体 类 的 静态 建 模 。21.4 节 介 绍 将 系统 组 织 为 一 组 对 象 的 方法 。 
21.5 节 介 绍 动态 建 模 ， 其 中 为 每 个 用 例 开发 了 交互 图 。21.6 节 描 述 ATM 的 状态 图 。21.7 节 到 
21.14 节 则 描述 “银行 系统 ”的 设计 模型 。 


21.1 问题 描述 


一 家 银行 拥有 一 些 АТМ 机 ( 自动 取款 机 )， 这 些 ATM 机 分 布 在 不 同 的 地 理 位 置 并 且 通 
过 广域网 连接 到 一 个 中 央 服 务 器 上 。 每 一 个 АТМ 机 由 一 个 读 卡 器 、 一 个 吐 钞 器 、 一 个 键盘 / 
显示 器 和 一 个 凭 条 打印 机 组 成 。 通 过 使 用 АТМ 机 ， 客 户 能 够 从 支票 账户 或 储蓄 账户 提取 现 
金 、 查 询 账户 余额 ， 或 者 在 账户 间 转 账 。 客 户 将 一 个 АТМ 卡 搬入 读 卡 器 后 会 启动 一 个 交易 。 
ATM 卡 背 面 的 磁 条 里 编码 保存 了 该 卡 的 卡号 、 生 效 期 和 失效 期 。 如 果 一 张 ATM 卡 能 够 被 系 
统 识 别 ， 那 么 系统 会 验证 这 张 卡 以 确定 该 卡 没 有 过 期 、 客 户 输入 的 PIN 码 (个 人 识别 码 ) 与 
系统 中 保留 的 PIN 码 匹 配 以 及 这 张 卡 没有 被 挂失 。 客 户 可 以 尝试 输入 三 次 PIN 码 ; 如 果 第 三 
次 输入 仍然 错误 ， 该 卡 会 被 没收 。 同 时 ， 被 确认 为 挂失 的 卡 也 会 被 没收 。 

如 果 输 入 的 PIN 码 通过 了 验证 ， 那 么 该 客户 可 以 进行 取款 、 查 询 或 转账 交易 。 在 取款 交 
易 被 许可 之 前 ， 系 统 需 确认 被 取款 账户 拥有 足够 的 金额 、 取 款额 度 未 超过 单 日 取款 上 限 以 及 
本 地 提 款 机 中 拥有 足够 的 现金 。 如 果 该 交易 获得 了 许可 ， 那 么 АТМ 机 将 提取 指定 的 取款 金 
额 、 打 印 包 含 交 易 信 息 的 凭 条 并 弹出 АТМ 卡 。 在 转账 交易 被 许可 前 ， 系 统 需 确认 客户 拥有 至 
少 两 个 账户 以 及 待 转 出 的 账户 中 拥有 足够 的 余额 。 对 于 被 允许 的 查询 和 转账 请 求 ，ATM 机 会 
打印 赁 条 并 弹出 АТМ 卡 。 客 户 可 以 在 任何 时 候 取消 交易 ， 如 果 交 易 被 取消 ,那么 АТМ 卡 也 
会 被 弹出 。 服 务 器 中 保留 了 所 有 的 客户 记录 、 账 户 记录 以 及 借 记 卡 记录 。 

一 个 ATM 操作 员 可 以 开启 或 关闭 ATM 机 ， 从 而 为 ATM 机 补充 现金 或 进行 常规 维护 工 
作 。 这 里 假设 开设 账户 、 关 闭 账户 和 创建 、 更 新 和 删除 客户 及 借 记 卡 记录 的 功能 由 现 有 的 系 
统 提 供 ， 这 些 并 不 是 本 案例 中 所 涉及 问题 的 一 部 分 。 


21.2 APRE 


用 例 在 用 例 模 型 中 描述 。 "银行 系统 ”的 用 例 模型 中 有 两 个 参与 者 (actor )， 即 “ATM 客 
户 ”( АТМ Customer ) 和 “操作 员 ”( Operator )， 二 者 都 是 系统 的 用 户 。 客 户 可 以 从 支票 账户 
或 储蓄 账户 中 取款 、 查 询 账 户 余额 以 及 在 账户 间 转 账 。 
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客户 通过 ATM 读 卡 器 和 键盘 与 系统 交互 。 参 与 者 是 客户 ， 而 非 读 卡 嚣 和 键盘 。 这 些 输 
入 设备 使 得 客户 可 以 启动 用 例 并 对 系统 的 提示 进行 响应 。 和 赁 条 打印 机 和 吐 钞 器 是 输出 设备 ， 
它们 也 不 是 参与 者 ， 因 为 从 这 些 用 例 中 受益 的 是 客户 。 

ATM 操作 员 可 以 关闭 ATM 机 、 为 ATM 的 吐 钞 器 补充 现金 并 启动 АТМ 机 。 参 与 者 代表 
了 由 用 户 扮演 的 角色 ， 因 此 系统 中 可 以 有 多 个 客户 和 操作 员 。 

现在 考虑 ATM 操作 员 用 例 。 一 种 方案 是 只 有 一 个 操作 员 用 例 ， 其 中 操作 员 关 闭 ATM 
机 、 添 加 现金 然后 启动 ATM 机 。 然 而 在 现实 中 也 有 可 能 出 现 以 下 情况 : 操作 员 关 闭 ATM 机 
是 因为 硬件 出 了 问题 而 不 是 要 添加 现金 ;操作 员 启 动 АТМ 机 是 因为 机 器 意外 关闭 。 因 此 ， 与 
单个 操作 员 用 例 的 方案 相 比 ， 一 种 更 好 的 方案 是 将 操作 员 用 例 分 为 三 个 用 例 ， 即 “添加 现金 ” 
(Add Cash )、“ 启 动 ”( Startup ) 和 “关闭 ”( Shutdown )， 如 图 21-1 所 示 。 
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^. «include» 
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А 
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Я 21-1 “银行 系统 ”用 例 模型 


再 考虑 由 “ATM 客户 ”所 触发 的 用 例 。 一 种 可 能 的 方案 是 为 客户 与 系统 之 间 所 有 的 交互 
建立 一 个 用 例 。 然 而 ， 由 客户 发 起 的 三 种 交易 类 型 ( 即 取 款 、 查 询 和 转账 ) 相互 之 间 非 常 独 
立 ， 区 分 很 明显 。 

因此 ， 我 们 开始 考虑 三 个 独立 的 “ATM 客户 ”用 例 ， 即 “取款 ”( Withdraw Funds )、“ 查 
询 账 户 ”( Query Account) 和 “转账 ”( Transfer Funds )， 每 个 用 例 对 应 一 种 交易 类 型 。 现 在 
考虑 “取款 ”用 例 。 该 用 例 的 主 序列 对 应 于 客户 成 功 取款 的 情况 ， 其 中 包括 读 取 ATM 卡 、 验 
证 客户 PIN 码 、 验 证 客户 的 账户 中 是 否 有 足够 的 金额 、( 如 果 通 过 验证 ) 提供 现金 、 打 印 赁 条 
和 弹出 ATM Fo 

然而 ， 通 过 比较 三 个 用 例 可 以 看 出 每 个 用 例 的 开始 部 分 ( 即 读 取 ATM 卡 和 验证 客户 PIN 
码 ) 对 于 所 有 这 三 个 用 例 都 是 一 样 的 。 因 此 ， 我 们 可 以 将 这 三 个 用 例 的 公共 部 分 提取 出 来 作 
为 一 个 称 为 “验证 PIN 码 ”(Validate PIN ) 的 包含 用 例 。 
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这 样 的 话 ,，“ 取 款 ”、“ 查 询 账户 ”和 “转账 ”这 三 个 用 例 就 可 以 描述 得 更 精简 一 点 ， 即 让 
它们 作为 包含 “验证 PIN 码 ” 用 例 的 具体 用 例 。 图 21-1 表示 了 用 例 之 间 的 关系 。 具 体 的 “ 取 
款 ” 用 例 首先 从 所 包含 的 “验证 РІМ 码 ” 包 含 用 例 的 描述 开始 ， 然 后 再 继续 “取款 ”用 例 的 描 
述 。 具 体 的 “转账 ”用 例 也 是 从 “验证 PIN 码 ” 包 含 用 例 的 描述 开始 ， 然 后 再 继续 “转账 ”用 
例 的 描述 。 修 改 后 的 具体 的 “查询 账户 ”用 例 也 是 如 此 。 包 含 用 例 和 具体 用 例会 在 下 文 阐述 。 

“验证 PIN 码 ” 用 例 的 主 序列 包括 读 取 АТМ 卡 、 验 证 客户 PIN A АТМ 卡 。 如 果 验 证 
通过 ， 系 统 会 提示 客户 选择 一 种 交易 : 取款 、 查 询 或 转账 。 其 他 分 支 则 处 理 所 有 可 能 的 错误 
情况 ， 例 如 客户 输入 了 错误 的 PIN 码 然后 系统 必须 重新 提示 ,或 者 ATM 卡 无 法 被 识别 或 被 
挂失 等 。 因 为 这 些 情况 可 以 很 容易 地 用 可 替换 序列 (alternative sequence ) 来 描述 ， 所 以 不 需 
要 将 这 些 情况 分 成 不 同 的 扩展 用 例 来 描述 。 


21.2.1 “验证 PIN 码 ” 用 例 


用 例 名 : 验证 PIN 码 
概述 : 系统 验证 客户 PING 
参与 者 : ATM 客户 
前 置 条 件 : АТМ 机 是 空 闪 的， 显示 着 欢迎 信息 
主 序列 : 
1. 客户 将 АТМ 卡 插入 读 卡 器 。 
2. 如 果 系 统 成 功 识别 该 卡 ， 那 么 读 取 该 卡 的 卡号 。 
3. 系统 提示 客户 输入 PIN 码 。 
4. 客户 输入 PIN 码 。 
5. 系统 检查 卡 的 失效 日 期 以 及 该 卡 是 否 已 被 挂失 (遗失 或 被 资 )。 
6. 如 果 该 卡 未 失效 ， 系 统 检查 用 户 输入 的 PIN 码 是 否 正确 。 
7. 如 果 PIN 码 正确 ， 系 统 检查 客户 的 哪些 账户 可 以 用 该 АТМ 卡 访问 。 
8. 系统 显示 可 访问 的 客户 账户 ， 并 提示 用 户 选 择 交易 类 型 : 取款 、 查 询 或 转账 。 
可 替换 序列 : 
步骤 2: 如 果 系 统 未 能 识别 该 卡 ， 那 么 系统 弹出 该 卡 。 
步骤 5: 如 果 系 统 确定 该 卡 失效 ， 那 么 系统 没收 该 卡 。 
步骤 5: 如 果 系 统 确定 该 卡 已 被 挂失 (遗失 或 被 次 )， 那 么 系统 没收 该 卡 。 
步骤 7: 如 果 客 户 输入 的 PIN 码 不 正确 ， 那 么 系统 提示 用 户 重 新 输入 PIN 码 。 
步骤 7: 如 果 客 户 输 错 PIN 码 三 次 ， 那 么 系统 没收 该 卡 。 
步骤 4 ~ 8: 如 果 用 户 选 择 “ 取 消 ”选项 ， 那 么 系统 取消 交易 并 弹出 ATM +. 
后 置 条 件 : 客户 的 PIN 码 已 被 验证 。 





21.2.2 具体 的 “取款 ”用 例 


FARIA: 取款 
概述 : 客户 从 一 个 有 效 账户 中 取出 一 定量 的 现金 
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参与 者 : ATM 客户 
KR: 包含 了 “验证 PIN Æ” (Validate РМ) 用 例 
前 置 条 件 : АТМ 机 是 空间 的 ， 显 示 着 欢迎 信息 374 
主 序列 : 
.包含 “验证 PIN 码 ” 用 例 的 步骤 。 
.客户 选择 “取款 ”选项 ， 输 入 取款 金额 并 选择 账户 号 。 
.系统 检查 客户 在 该 账户 中 的 余额 是 否 足够 以 及 用 户 所 输入 的 取款 金额 是 否 超 
过 取款 上 限 。 
4. 如 果 通 过 所 有 上 述 检 查 ， 系 统 授 权 通 过 本 次 取款 请 求 。 
5. 系统 分 发 相应 数额 的 现金 。 
6. 系统 打印 赁 条 ， 显 示 交 易 号 、 交 易 类 型 、 取 款 金 额 和 账户 余额 信息 。 
7. 系统 弹出 АТМ +. 
8. 系统 显示 欢迎 信息 。 
可 替换 序列 : 
БЕ З. 如 果 系 统 确定 所 选 账户 号 无 效 ， 那 么 系统 显示 错误 信息 并 弹出 ATM 卡 。 
步骤 3 : 如 果 系 统 确定 客户 账户 上 没有 足够 的 金额 ， 那 么 系统 显示 道歉 信息 并 弹出 
ATM 卡 。 
步骤 3: 如 果 系 统 确定 取款 金额 超过 了 每 日 取款 上 限 ， 那 么 系统 显示 道歉 信息 并 弹出 
ATM 卡 。 
步骤 5: 如 果 ATM 机 现金 不 够 ， 那 么 系统 显示 道歉 信息 、 弹 出 АТМ 卡 并 关闭 机 器 。 
后 置 条 件 : 客户 账户 的 金额 已 被 扣除 。 





21.23 ”具体 的 “查询 账户 ”用 例 


用 例 名 : 查询 账户 
参与 者 : ATM 客户 
概述 : 客户 得 知 一 个 有 效 银行 账户 的 余额 
依赖 : 包含 了 “验证 PIN 码 ”( Validate РМ) 用 例 
前 置 条 件 : АТМ 机 是 空闲 的 ， 显 示 着 欢迎 信息 
主 序列 : 

1. 包含 “验证 PIN 码 ” 用 例 的 步骤 。 

2. 客户 选择 “查询 ”选项 ， 并 输入 账户 号 码 。 


3. 系统 读 取 账户 余额 。 
4. 系统 打印 赁 条， 显示 交易 号 、 交 易 类 型 和 账户 余额 信息 。 
5. 系统 弹出 ATM 卡 。 
6. 系统 显示 欢迎 信息 。 
可 替换 序列 : 
步骤 3: 如 果 系 统 确定 所 选 账户 号 无 效 ， 那 么 系统 显示 错误 信息 并 弹出 ATM Fo 
后 置 条 件 : 客户 查询 了 账户 。 375 





286 ORD R HAR 


21.24 具体 的 “转账 ”用 例 


用 例 名 : 转账 
概述 : 客户 将 一 定数 额 的 资金 从 一 个 有 效 账户 转 到 另 一 个 有 效 账户 
参与 者 : ATM 客户 
依赖 : 包含 了 “验证 PIN Æ” (Validate РМ) 用 例 
前 置 条 件 : ATM 机 是 空 闪 的， 显示 着 欢迎 信息 
主 序列 : 
1. 包含 “验证 PIN 码 ” 用 例 的 步骤 。 
2. 客户 选择 “转账 ”选项 并 输入 转账 “金额 ”(amount)、“ 转 出 账户 ”(from 
account ) 和 “ 转 入 账户 ”( to account )。 
3. 如 果 系 统 确定 “ 转 出 账户 ”里 有 足够 的 金额 ， 那 么 系统 进行 转账 。 
4. 系统 打印 凭 条 ， 显 示 交 易 号 、 交 易 类 型 、 转 账 金额 和 账户 余额 信息 。 
5. 系统 弹出 ATM 卡 。 
6. 系统 显示 欢迎 信息 。 
可 替换 序列 : 
ЖЕЗ. 如 果 系 统 确定 “ 转 出 账户 ”号 码 无 效 ， 那 么 系统 显示 错误 信息 并 弹出 ATM 卡 。 
步骤 3: 如 果 系 统 确定 “ 转 入 账户 ”号 码 无 效 ， 那 么 系统 显示 错误 信息 并 弹出 ATM Е. 
步骤 3: 如果 系 统 确定 客户 的 “ 转 出 账户 ”上 没有 足够 的 金额 ， 那 么 系统 显示 道歉 信 
息 并 弹出 ATM 卡 。 
后 置 条 件 : 客户 资金 从 指定 的 “ 转 出 账户 ” 转 到 指定 的 “ 转 入 账户 ”。 





21.3 ”静态 建 模 


本 节 首 先 对 问题 域 和 系统 上 下 文 进行 了 考虑 ， 然 后 讨论 实体 类 的 静态 建 模 。 可 同时 参阅 
第 7 章 ， 其 中 用 “银行 系统 ”的 例子 详细 介绍 了 静态 建 模 。 


21.3.1 问题 域 的 静态 建 模 


图 21-2 中 的 类 图 描述 了 问题 域 中 的 概念 静态 模型 。 一 个 银行 有 若干 ATM 机 。 每 个 
АТМ 机 被 建 模 为 一 个 复合 类 ， 其 中 包含 “ 读 卡 器 ”( Сага Reader )、 一 个 “ 吐 钞 器 ”( Cash 
Dispenser )、 一 个 “和 赁 条 打印 机 ”(Receipt Printer) 和 一 个 用 来 和 用 户 交 互 的 “ATM 客户 键 
Ж /显示 器 ”( ATM Customer Keyboard Display )。“ATM 客户 ”参与 者 将 卡 插 和 人“ 读 卡 器 ” 
并 通过 “ATM 客户 键盘 / 显示 器 ”对 系统 的 提示 做 出 响应 “和 赁 条 打印 机 ”为 “ATM 客户 ” 
参与 者 打印 赁 条 。 此 外 ,“ATM 操作 员 ” 参 与 者 是 专门 维护 АТМ 机 的 人 员 。 


21.32 ”系统 上 下 文 的 静态 建 模 


软件 系统 的 上 下 文 类 图 使 用 静态 建 模 表示 法 ,将 “银行 系统 ”看 做 一 个 聚合 类 ， 描 述 了 
与 “银行 系统 ”存在 交互 关系 的 外 部 类 。 正 如 第 7 章 所 述 ， 我 们 通过 考虑 问题 域 的 静态 建 模 
过 程 中 所 确定 的 物理 类 来 开发 上 下 文 类 图 。 
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Р 21-2 问题 域 的 概念 静态 模型 


如 图 7-19 所 示 ， 从 整个 系统 ( 包括 硬件 和 软件 ) 的 角度 看 , “АТМ 客户 ”和 “ATM 操作 
员 ” 参 与 者 都 位 于 系统 外 部 。“ATM 操作 员 ” 通 过 键盘 / 显示 器 与 系统 交互 。“ATM 客户 ” 参 
与 者 通过 读 卡 器 、 吐 钞 器 、 赁 条 打印 机 和 ATM 客户 键盘 / 显示 器 等 输入 /输出 (IO ) 设备 与 
系统 交互 。 从 整个 软 硬 件 系统 的 角度 来 说 ， 这 些 输入 /输出 设备 是 系统 的 一 部 分 。 从 软件 的 
角度 来 说 ， 这 些 输入 /输出 设备 位 于 软件 系统 的 外 部 。 在 软件 系统 的 上 下 文 类 图 中 ， 输 入 / 输 
出 设备 则 被 建 模 为 外 部 类 ， 如 图 21-3 所 示 。 
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图 21-3 “银行 系统 ”软件 上 下 文 类 图 


“АТМ 客户 ”参与 者 使 用 的 四 个 外 部 类 是 “ 读 卡 器 ”"“ 吐 钞 器 "“ 和 赁 条 打印 机 ”和 
“ATM 客户 键盘 /显示 器 ”; “АТМ 操作 员 ” 通 过 键盘 / 显示 器 与 系统 交互 。 如 第 7 章 所 述 ， 
“АТМ 客户 ”和 “ATM 操作 员 ” 都 被 建 模 为 外 部 用 户 。ATM 机 的 每 一 个 外 部 类 都 有 一 个 实例 。 
“银行 系统 ”( 见 图 21-3 ) 的 软件 系统 上 下 文 类 图 把 软件 系统 刻画 为 一 个 聚合 类 ， 该 类 从 外 部 
类 接收 消息 同时 也 向 它们 发 送 消息 。 
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21.3.3 ”实体 类 的 静态 建 模 


图 21-4 描述 了 实体 类 的 静态 模型 ， 即 实体 类 模型 。 图 21-5、 图 21-6 和 图 21-7 给 出 了 每 
个 实体 类 的 属性 。 





«entity» «entity» «entity» 
Bank Customer DebitCard 


customerName: String cardld: String 
customerld: String PIN: String 
customerAddress: String startDate: Date 
expirationDate: Date 
status: Integer 
limit: Real 
total: Real 


«entity» «entity» 
CheckingAccount SavingsAccount 


lastDepositAmount: Real interest: Real 





bankName: String 
bankAddress: String 
Балка: Real 





«entity» 
Account 


accountNumber: String 
accountType: String 
balance: Real 








21-5 “银行 系统 ”的 概念 静态 模型 : 类 属性 


«entity» 
ATMTransaction 


bankld: String 

АТМЮ: String 

date: Date 

time: Time 
transactionType: String 
cardid: String 

PIN: String 

status: Integer 























«entity» «entity» «entity» ‚ «entity» 
WithdrawalTransaction QueryTransaction TransferTransaction PiINValidationTransaction 
accountNumber; String accountNumber: String fromAccountNumber: String 
amount: Real balance: Real toAccountNumber: String 


balance: Real lastDepositAmount: Real 


amount: Real 


startDate: Date 
expirationDate: Date 


Я 21-6 “银行 系统 ”的 概念 静态 模型 : 类 属性 (88) 


«entity» «entity» 

CardAccount ATMInfo 
cardld: String bankld: String 
accountNumber: String АТМ: String 


accountType: String ATMLocation: String 
ATMAddress: String 





«entity» «entity» 
ATMCash ATMCard 


cashAvailable: Integer cardid: String 

fives: Integer startDate: Date 
tens: Integer expirationDate: Date 
twenties: Integer 





图 21-7 “银行 系统 ”的 概念 静态 模型 : 类 属性 ( BE ) 


Я 21-4 描述 了 “银行 ”( Bank ) 实体 类 ， 它 和 “客户 ”(Customer ) 类 以 及 “ 借 记 卡 ” 
( Debit Card ) 类 之 间 存 在 一 对 多 的 关系 。 该 实体 类 比较 特别 ， 因 为 它 只 有 一 个 实例 ; 它 的 属 
性 包括 “银行 名 称 ”( bank Name )、“ 银 行 地 址 ”( bank Address ) 和 “银行 号 ”( bank Id )。“ 客 
户 ” 类 和 “账户 ”( Account ) 类 存在 多 对 多 的 关系 。 由 于 存在 支票 账户 ( Checking Account ) 
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和 储蓄 账户 (Savings Account) 且 两 者 有 部 分 公共 属性 ， 因 此 “账户 ”类 可 以 被 特 化 为 “ 支 
票 账户 ”类 和 “储蓄 账户 ”类 。 这 样 两 个 子 类 可 以 共享 一 些 属性 ， 即 “账户 号 ”( account 
Number ) “上 账户 类 型 ”(account Туре) 和 “余额 ”( balance )。 其 他 属性 则 为 “支票 账户 ” 
( 如 最 后 一 次 “存款 金额 ”( Deposit Amount )) 和 “储蓄 账户 ”( 如 累计 的 “利息 ”( interest ) ) 
所 专 有 。 

“ATM 交易 ”( АТМ Transaction ) 类 可 以 修改 “账户 ”类 ， 而 “ATM 交易 ”类 又 能 被 进 
一 步 特 化 为 各 种 不 同类 型 的 交易 类 ， 包 括 “ 取 款 交 易 ”( Withdrawal Transaction) Ж, “Ж 
交易 ”( Query Transaction ) 类 、“ 转 账 交 易 ”( Transfer Transaction ) 类 或 “PIN 码 验 证 交易 ” 
(РМ Validation Transaction) 类 。“ATM 交易 ” 父 类 包含 交易 类 的 共有 属性 ,包括 “交易 号 ” 
( transaction Id ) ( 该 属性 实际 上 是 由 “银行 号 ”、“ATM 号 ”、“ 日 期 ”和 和 “时间” 这 些 属性 拼 
Вет AL). “交易 类 型 ”( transaction Type )、“ 卡 号 ”(card Id), “PIN #3” (PIN) 和 “状态 ” 
(status )， 其 他 属性 则 为 特定 类 型 的 交易 类 所 专 有 。 因 此 ， 对 于 “取款 交易 ” 子 类 ， 它 所 专 
有 的 属性 包括 “账户 号 ”( account Number), “人 金额 ”( amount ) 和 “余额 ”( balance )。 对 于 
“转账 交易 ” 子 类 ， 它 所 专 有 的 属性 是 “ 转 出 账户 号 ”( тот Account Number ) ( 可 以 是 支票 账 
户 或 储蓄 账户 )、“ 转 入 账户 号 ”( to from Account Number ) ( 可 以 是 支票 账户 或 储蓄 账户 ) 以 
及 “金额 ”( amount )。 

还 有 一 个 “ 卡 账户 ”( Сага Account) 关联 类 。 这 种 类 用 于 所 要 描述 的 属性 属于 关联 关系 
而 非 关联 关系 所 连接 的 类 的 情况 。 这 样 ， 在 “ 借 记 卡 ” 类 和 “账户 ”类 之 间 的 多 对 多 关联 中 ， 
能 被 某 张 借 记 卡 所 访问 的 个 人 账户 应 该 是 “ 卡 账户 ”( Сага Account) 这 一 关联 类 的 属性 ， 而 
非 “ 借 记 卡 ” 类 或 “账户 ”类 的 属性 。 卡 账户 类 的 属性 是 卡号 (Card Id), IKAS (account 
Number ) 和 账户 类 型 (account Type )。 

此 外 ， 也 需要 用 实体 类 建 模 21.2 节 中 描述 的 其 他 信息 。 例 如 ， 用 “ATM 卡 ”( ATM 
Сага) 类 来 表示 塑料 卡 的 磁 条 上 所 读 出 的 信息 ; ЈЕ “АТМ 现金 ”( АТМ Cash ) 类 表示 在 ATM 
机 中 5 美元 、10 美元 或 20 美元 面额 的 现金 ; Н “GEAR” (Receipt) 类 表示 关于 一 个 交易 的 信 
息 ， 但 由 于 它 和 前 面 描述 的 交易 类 的 信息 是 一 样 的 ， 因 此 就 没有 必要 单独 表示 为 一 个 类 了 。 


214 ”对象 组 织 


我 们 接 下 来 考虑 将 系统 分 解 为 对 象 ， 为 后 面 定义 动态 模型 做 好 准备 。 对 象 组 织 准 则 可 以 
帮助 我 们 确定 系统 中 的 对 象 。 在 类 和 对 象 确定 之 后 ， 我 们 会 为 每 一 个 用 例 开发 通信 图 或 顺序 
图 来 表示 用 例 中 的 对 象 以 及 它们 之 间 的 动态 交互 顺序 。 


2141 客户 端 / 服 务 器 子 系统 组 织 


由 于 “银行 系统 ”是 一 个 客户 端 /服务 器 应 用 ， 一 些 对 象 属于 АТМ 客户 端 而 另 一 些 对 象 
则 属于 银行 服务 ， 因 此 我 们 从 识别 作为 聚合 或 组 合 对 象 的 子 系统 开始 。 在 客户 端 /服务 器 系 
统 中 ， 子 系统 很 好 确定 。 这 样 ， 在 “银行 系统 ”中 有 一 个 客户 端子 系统 称 为 “ATM 客户 端子 
系统 ”( ATM Client Subsystem )， 每 个 ATM 机 上 运行 着 它 的 一 个 实例 。 还 有 一 个 服务 子 系统 
称 为 “银行 服务 子 系统 ”( Banking Service Subsystem )， 它 只 有 一 个 实例 ( 图 21-8 )。 这 是 一 
个 基于 地 理 分 布 的 子 系统 组 织 的 例子 ， 其 中 的 地 理 分 布 已 经 在 问题 描述 中 明确 了 。 “银行 服务 
子 系统 ”和 “ATM 客户 端子 系统 ”这 两 个 子 系统 都 被 描述 为 聚合 类 ， 并 且 二 者 之 间 存 在 一 对 
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多 关联 。 所 有 的 外 部 类 都 和 “ATM 客户 端子 系统 ”进行 交互 和 通信 。 


«extemal user» 
Operator 
«software system» 
BankingSystem 
1 
снег Requests service from 
tue 1 


« t» 
«subsystem» » 
ATMClient - 


p Subsystem 

















«external output 
device» 
ReceiptPrinter 


«external /О 
device» 
CardReader 
«external output |1 
device» 
CashDispenser 


21.4.2 АТМ 客户 端 对 象 和 类 的 组 织 : 边界 对 象 


下 一 步 是 要 确定 “ATM 客户 端 ” 中 的 对 象 和 类 。 首 先 考 虑 边界 对 象 和 边界 类 。 边 界 类 可 
以 基于 软件 系统 的 上 下 文 图 来 确定 ， 如 图 21-9 所 示 ， 该 图 将 “银行 系统 ”显示 为 一 个 聚合 类 。 

我 们 为 每 个 外 部 类 设计 一 个 边界 类 。 输 入 /输出 设备 类 包括 :“ 读 卡 器 接口 ”(Card 
Reader Interface ), ATM 卡 是 通过 这 个 接口 读 取 的 ;“ 吐 钞 器 接口 ”( Cash Dispenser Interface ), 
用 来 分 发 现金 ;“ 赁 条 打印 机 接口 ”( Receipt Printer Interface )， 用 于 打印 赁 条 。 此 外 还 有 
“客户 交互 ”( Customer Interaction) 类 ， 这 是 一 个 通过 键盘 /显示 器 和 客户 交互 的 用 户 交 
互 类 ， 能 够 显示 文本 消息 、 提 示 客 户 进行 操作 并 接收 客户 输入 。“ 操 作 员 接口 ”(Operator 
Interaction ) 类 是 一 个 和 ATM 操作 员 (为 ATM 机 补充 现金 ) 交互 的 用 户 交 互 类 。 一 个 ATM 
机 的 每 个 边界 类 都 只 有 一 个 实例 。 






«service» 
«subsystem» 
BankingService 
Subsystem 




















«extemal user» 
ATMCustomer 
KeypadDisplay 






Е 21-8 银行 系统 : 主要 子 系统 





«software system» 
BankingSystem 











«external output 
device» 
ReceiptPrinter 


«output» 
ReceiptPrinter 














«external изег» 
ATMCustomer 







«external output 
device» 


CashDispenser 









Interface 


图 21-9 “银行 系统 ”的 外 部 类 和 边界 类 
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21.4.3 АТМ 客户 端 对 象 和 类 的 组 织 : 用 例 中 的 对 象 


接 下 来 ， 我 们 考虑 单个 用 例 以 及 参与 用 例 的 对 象 。 首 先 ， 考 虑 “验证 PIN 码 ” 这 一 包含 
用 例 ， 该 用 例 描 述 了 客户 如 何 将 ATM 卡 插入 读 卡 器 、 系 统 如 何 提 示 客 户 输入 PIN 码 以 及 系 
统 如 何 检查 客户 输入 的 PIN 码 是 否 正确 。 该 用 例 中 ,我 们 首先 确认 “ 读 卡 器 接口 ”对 象 是 否 
需要 读 取 АТМ 卡 。 由 于 需要 保存 从 АТМ 卡 上 读 取 的 信息 ， 所 以 我 们 可 以 确定 这 里 需要 一 个 
实体 对 象 来 存储 “ATM 卡 ” 信 息 。“ 客 户 交互 ”对 象 用 来 通过 键盘 / 显示 器 与 客户 交互 ， 在 这 
里 ， 该 对 象 用 来 提示 客户 输入 PIN 码 。 发 送 给 “银行 服务 子 系统 ”用 来 验证 PIN 码 的 信息 被 
保存 在 一 个 “ATM 交易 ”对 象 中 。 为 了 验证 PIN 码 ， 交 易 信 息 需 要 包含 PIN 码 以 及 АТМ F 
号 。 为 了 保证 ATM 机 中 各 活动 执行 的 顺序 ， 我 们 确定 还 需要 一 个 控制 对 象 ， 即 “ATM 控制 ” 
( ATM Control )。 

下 面 考虑 “取款 ”用 例 ， 如 果 PIN 码 有 效 且 客户 选择 了 取款 选项 则 会 进入 该 用 例 。 在 
该 用 例 中 ， 客 户 输入 取款 金额 以 及 借 记 卡号 ， 然 后 系统 验证 是 否 能 授权 该 取款 操作 。 如 果 
验证 通过 ， 系 统 分 发 现金 、 打 印 凭 条 并 弹出 АТМ 卡 。 该 用 例 需 要 额外 的 对 象 。 客 户 取款 的 
信息 (包括 账户 号 及 取款 金额 ) 需要 存储 在 “ATM 交易 ”对 象 中 。 为 了 分 发 现金 ， 需 要 一 
个 “ 吐 钞 器 接口 ”对 象 。 我 们 还 需要 维护 АТМ 机 中 现金 的 数量 ， 因 此 确定 需要 一 个 称 作 
“ATM 现金 ”( ATM Cash ) 的 实体 对 象 ， 该 对 象 的 值 随 着 每 次 取款 而 相应 减少 。 最 后 ， 需 要 
一 个 “ 赁 条 打印 机 接口 ”对 象 来 打印 赁 条 。 和 前 面 一 样 , “АТМ 控制 ”对 象 控制 该 用 例 的 执 
行 序列 。 

检查 完 其 他 用 例 ， 我 们 发 现 还 需要 一 个 额外 的 对 象 ， 即 “操作 员 交 互 ”( Operator 
Interaction) 对 象 ， 该 对 象 用 于 所 有 由 ATM“ 操 作 员 参与 者 ”发 起 的 用 例 。 “操作 员 交 互 ”对 
象 需要 向 “ATM 控制 ”发 送 “ 启 动 ”( startup ) 和 “关闭 ”( shutdown ) 事件 ， 这 是 因为 操作 
员 维 护 ATM 机 和 客户 使 用 ATM 机 这 两 件 事情 不 能 同时 进行 。 

基于 以 上 分 析 ， 我们 可 以 得 到 如 图 21-10 所 示 的 “ATM 客户 端子 系统 ”中 的 类 ， 这 些 类 
都 被 表示 为 聚合 类 。 除 了 图 21-9 中 的 三 个 输入 /输出 设备 类 和 两 个 用 户 交互 类 ， 还 有 三 个 实 
体 类 和 一 个 状态 相关 的 控制 类 。 

«client» 
«subsystem» 
ATMClient 
«state dependent 


ntrol» 


ATMControl 


«ИО» 
CardReader 
Interface 


«user 
interaction» 
Operator 
«output» entity» Interaction 
ReceiptPrinter 


Interface «user interaction» 


Customer 
Interaction 
«output» 
CashDispenser 
Interface 





图 21-10 АТМ 客户 端子 系统 类 
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2144 ”服务 子 系统 中 的 对 象 组 织 


有 些 实体 对 象 的 作用 范围 涉及 整个 银行 ， 所 有 的 АТМ 机 都 需要 访问 这 些 对 象 。 因 此 ， 
这 些 对 象 需要 保存 在 服务 器 端的 “银行 服务 子 系统 ”中 。 这 些 对 象 包 括 含 有 银行 客户 信息 的 
“Z” (Customer) 对 象 、 含 有 各 个 银行 账户 信息 的 “账户 ”(Account ) WA (包括 支票 账 
户 和 储蓄 账户 ) 以 及 包含 银行 所 维护 的 所 有 借 记 卡 信息 的 “ 借 记 卡 ”( Debit Сага) 对 象 。 这 
些 对 象 所 对 应 的 类 都 包含 在 图 21-4 所 描述 的 实体 类 的 静态 模型 中 。 

“银行 服务 子 系 统 ” 中 的 实体 类 包括 “客户 ” 超 类 、“ 账 户 ” 超 类 、“ 文 票 账户 ” 子 类 、 
“储蓄 账户 ” 子 类 以 及 “ 借 记 卡 ” 类 。 还 有 一 个 “ATM 交易 ”对 象 ， 该 对 象 需要 从 客户 端 发 
送 到 服务 器 。 客 户 端 向 “银行 服务 ”发 送 交 易 请 求 ， 然 后 “银行 服务 ”向 客户 端 返回 一 个 响 
应 。 交 易 信 息 作 为 一 个 实体 对 象 以 “交易 日 志 ”( Transaction Log) 的 形式 保存 在 服务 器 端 ， 
从 而 记录 交易 历史 。 作 为 ATM 交易 消息 一 部 分 的 临时 交易 数据 可 能 与 持久 化 的 交易 数据 有 所 
不 同 ， 例 如 交易 状态 在 交易 结束 之 后 是 已 知 的 ， 但 在 交易 过 程 中 却 是 未 知 的 。 

为 了 处 理 客 户 请 求 ， 服 务 器 端 还 需要 业务 逻辑 对 象 来 定义 特定 业务 的 应 用 逻辑 。 具 体 而 
言 ， 每 一 种 АТМ 交易 类 型 都 需要 一 个 交易 管理 器 类 来 定义 处 理 交 易 的 业务 规则 。 业 务 逻 辑 对 
象 包括 “PIN 码 验 证 交易 管理 器 ”( PIN Validation Transaction Manager ) “取款 交易 管理 器 ” 
( Withdrawal Transaction Manager ) “查询 交易 管理 器 ”( Query Transaction Manager ) 和 “ 转 
账 交易 管理 器 ”( Transfer Transaction Manager )。 例 如 ， 在 “取款 交易 管理 器 ”类 中 定义 的 业 
务 规则 是 : (1) 账户 在 取款 之 后 余额 必须 大 于 等 于 零 ; (2) 取款 金额 不 能 超过 每 日 取款 上 限 ， 
上 限 的 值 由 “ 借 记 卡 ”实体 类 的 “限额 ”( limit ) 属性 给 出 。 


21.5 动态 建 模 


动态 模型 描述 了 参与 每 个 用 例 的 对 象 之 间 的 交互 。 开 发 动态 模型 的 起 点 是 用 例 以 及 对 象 
结构 组 织 过 程 中 所 确定 的 对 象 。 满 足 每 个 用 例 需要 的 对 象 间 消息 通信 序列 可 以 用 顺序 图 或 通 
信 图 描述 。 通 常 只 需要 在 两 者 中 选择 一 个 就 足够 了 。 在 本 例 中 ， 我 们 将 客户 端子 系统 的 这 两 
种 图 都 画 出 来 以 便 进 行 比较 。 

由 于 “银行 系统 ”是 一 个 客户 端 /服务 器 系统 ， 因 此 在 此 之 前 已 经 确定 将 系统 的 结构 分 
解 为 客户 端 和 服务 子 系统 ， 如 图 21-8 所 示 。 我 们 用 通信 图 来 表示 客户 端 和 服务 子 系统 。 

图 21-11 和 图 21-16 中 所 描述 的 通信 图 是 用 来 实现 АТМ 客户 端 “验证 PIN 码 ” 用 例 和 
“取款 ”用 例 的 。 通 信和 图 也 可 以 用 来 实现 АТМ 客户 端的 “转账 ”用 例 、“ 查 询 账 户 ” 用 例 以 及 
由 操作 员 触 发 的 各 个 用 例 。 

ATM 客户 端的 “验证 PIN 码 ” 和 “取款 ”的 通信 图 是 状态 相关 的 。“ATM 控制 ”对 象 
定义 了 交互 中 状态 相关 的 部 分 ， 这 一 部 分 执行 了 ATM 状态 图 。 我 们 用 状态 相关 的 动态 分 析 
方法 来 确定 对 象 之 间 是 如 何 交互 的 。 图 21-13 和 图 21-18 中 的 状态 图 分 别 展示 了 这 两 种 用 例 。 
21.5.1 节 和 21.5.3 节 分 别 介绍 了 这 两 个 客户 端 用 例 的 动态 分 析 。 

银行 服务 按照 收 到 请 求 的 先后 顺序 处 理 来 自 多 个 ATM 机 的 交易 。 每 个 交易 的 处 理 都 是 
完整 和 自 包 含 的 ， 所 以 用 例 中 的 银行 服务 部 分 不 是 状态 相关 的 。 因 此 ， 这 些 用 例 需 要 一 个 无 
状态 的 动态 分 析 。 服 务 器 端 “验证 PIN 码 ”和 “取款 ”用 例 的 通信 图 在 图 21-14 和 图 21-19 
中 给 出 。 这 两 个 服务 器 端 用 例 的 动态 分 析 分 别 在 21.5.2 节 和 21.5.4 节 中 给 出 。 

考虑 对 象 之 间 是 如 何 交 互 的 。 我 们 针对 “验证 РІМ 码 ” 和 “取款 ”用 例 给 出 了 详细 
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的 例子 。 在 客户 端 ， 给 出 了 通信 图 和 顺序 图 。 在 两 种 图 中 ， 消 息 序列 的 编号 和 描述 都 是 一 
样 的 。 


21.5.1 客户 端 验证 PIN 码 交 互 图 的 消息 序列 描述 


客户 端的 “验证 PIN 码 ” 交 互 图 起 始 于 客户 将 АТМ 卡 插入 读 卡 器 。 该 消息 的 顺序 编号 
起 始 于 1， 这 是 由 参与 者 发 起 的 第 一 个 外 部 事件 。 表 示 到 达 系 统 中 软件 对 象 的 消息 的 后 续 编 
号 分 别 为 1.1、1.2、1.3， 最 后 结束 于 1.4， 表 示 系 统 显 示 给 参与 者 的 响应 。 参 与 者 的 下 一 个 输 
入 是 编号 为 2 的 外 部 事件 ， 随 后 是 内 部 事件 2.1、2.2 等 。 后 续 的 消息 序列 描述 对 应 于 图 21-11 
中 的 通信 图 以 及 图 21-12 中 的 顺序 图 。 









«client» 










:ATMClient 







(PIN Validation Transaction) 


2.6: Validate PIN 
{Account #s) 


2.7 [Valid]: 
| Valid PIN 


1.4: PIN Prompt, 
9: Selection Ма 





«external user» 
: ATMCustomer 
KeypadDisplay 


2: PIN Input 


PIN Validation Transaction = {transactionld, transactionType, cardid, PIN, starDate, expirationDate} 


Р 21-11 通信 图 : ATM 客户 端 “ 验 证 PIN ЇЗ” НИЯ 


由 于 “验证 PIN 码 ” 交 互 图 是 状态 相关 的 ， 因 此 有 必要 考虑 由 “ATM 控制 ”对 象 执行 的 
АТМ 状态 图 。 具 体 而 言 ， 需 要 考虑 状态 图 ( 见 图 21-13) ЯП “АТМ 控制 ”对 象 СИНА) 
之 间 的 交互 。 下 面 的 消息 序列 阐述 了 该 状态 图 的 状态 和 转移 ， 对 应 于 图 21-11 中 的 通信 图 和 
图 21-12 中 的 顺序 图 中 的 事件 。 消 息 序列 描述 如 下 : 


385 1: “АТМ 客户 ”参与 者 将 ATM 卡 插入 “ 读 卡 器 "。“ 读 卡 器 接口 ”对 象 读 取 卡 中 信息 。 
1.1 :“ 读 卡 器 接口 ”将 ATM 卡 输入 数据 (包含 了 “卡号 ”“ 生 效 日 期 “失效 日 
Ў”) 发 送 给 “ATM 卡 ” 实 体 对 象 。 
1.2 :“ 读 卡 器 接口 ”将 “卡片 插入 ”( Card Inserted) 的 消息 发 送 给 “ATM 控制 ”对 
Ro “卡片 插入 ”事件 使 得 “ATM 控制 ”状态 图 从 空闲 状态 〈 初始 状态 ) 转移 到 “等 待 


PIN 码 输入 ”( Waiting for РМ) 状态 。 与 该 转移 关联 的 输出 事件 是 “获取 PIN 码 ”( Get 
PIN )。 

1.3: “АТМ 控制 ”将 “获取 PIN 码 ” 消 息 发 送 给 “客户 交互 ”对 象 。 

1.4:“ 客 户 交互 ”对 象 将 “PIN 码 提 示 ” 显 示 给 “ATM 客户 ”参与 者 。 
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Entry / 
Display Welcome 






1.2: Card Inserted / 
1.3: Get PIN 






Waiting for PIN 


2.5: PIN Entered / 
2.6: Validate PIN 


Validating PIN 


2.7 [Valid]: Valid PIN / 
2.8: Display Menu, 
2.8а: Update Status 









Waiting for 
Customer Choice 


Р 21-13 “ATM 控制 ”的 状态 图 :“ 验 证 PIN E” НЯ 


2: “АТМ 客户 ”向 “客户 交互 ”对 象 输入 PIN 码 。 

2.1:“ 客 户 交互 ”对 象 向 “ATM 卡 ” 请 求 卡 数据 。 

2.2: “АТМ 卡 ” 向 “客户 交互 ”对 象 提 供 卡 数据 。 

2.3 : “客户 交互 ”向 “ATM 交易 ”实体 对 象 发 送 “ 卡 号 ”、“PIN 码 ”、“ 生 效 日 期 ” 

“失效 日 期 ”。 

2.4: “ATM 交易 ”实体 对 象 向 “客户 交互 ”发 送 “PIN 码 验 证 交易 ”。 

2.5 :“ 客 户 交互 ”对 象 向 “ATM 控制 ”发 送 “PIN 码 已 输入 ”(PIN Entered ) (“РМ 
码 验 证 交易 ”) 的 消息 。“PIN 码 已 输入 ”事件 使 得 “ATM 控制 ”状态 图 从 “等 待 PIN 码 
输入 ”状态 转移 到 “验证 PIN 码 ” 状 态 。 与 该 转移 关联 的 输出 事件 是 “验证 PIN 码 ”。 

2.6: “АТМ 控制 ”向 “银行 服务 ”发 送 一 个 “验证 PIN 码 ”(“PIN 码 验 证 交易 ”) 的 
请 求 。 

2.7 :“ 银 行 服务 ”验证 PIN 码 并 向 “ATM 控制 ”发 送 “ 有 效 PIN Æ” (Valid PIN) 
的 响应 。 然 后 ,“ATM 控制 ”转移 到 “等 待 客户 选择 ”( Waiting for Customer Choice ) Ж 
态 。 该 转移 的 输出 事件 是 与 “ATM 控制 ”对 象 发 送 的 输出 消息 相对 应 的 “显示 菜单 ” 
(Display Menu ) 和 “更 新 状态 ”( Update Status )。 

2.8: “АТМ 控制 ”对 象 向 “客户 交互 ”对 象 发 送 “ 显 示 菜 单 ” 消 息 。 

2.8a: “ATM 控制 ”对 象 向 “ATM 交易 ”对 象 发 送 “ 更 新 状态 ”消息 。 

2.9:“ 客 户 交互 ”向 “ATM 客户 ”显示 包含 “取款 ”"、“ 查 询 ” 和 “转账 ”选项 的 菜单 。 





与 “验证 PIN 码 ” 用 例 中 的 可 替换 场景 序列 相对 应 的 可 替换 场景 的 动态 建 模 在 第 11 章 中 
进行 了 描述 。 可 替换 场景 是 基于 交互 图 和 状态 图 描述 的 。 
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21.5.2 ”服务 器 端 验证 РИМ 码 交 互 图 的 消息 序列 描述 


现在 考虑 服务 器 端 “ 验 证 PIN 码 ” 包 含 用 例 的 交互 图 。“ 借 记 卡 ”实体 对 象 包 含 了 银行 
中 所 有 借 记 卡 的 相关 信息 ， 在 服务 器 验证 PIN 码 时 需要 访问 该 对 象 。 一 张 借 记 卡 可 访问 多 个 
账户 ， 如 果 PIN 码 验证 通过 ， 需 要 访问 “ 卡 账户 ”实体 对 象 来 获得 这 些 账 户 的 账户 号 。 

此 外 ， 每 个 交易 都 有 一 个 业务 逻辑 对 象 ， 该 对 象 封 装 了 管理 交易 执行 的 业务 应 用 逻辑 。 
业务 逻辑 对 象 从 客户 端的 “ATM 控制 ”对 象 接收 交易 请 求 ， 然 后 与 实体 对 象 交 互 以 确定 向 
“ATM 控制 ”对 象 返回 什么 样 的 响应 。 例 如 ,“PIN 码 验证 ”交易 的 业务 逻辑 对 象 是 “PIN 码 
验证 交易 管理 器 ”对 象 。 

以 下 服务 器 端 “ 验 证 PIN 码 ” 交 互 图 的 消息 序列 描述 对 应 于 图 21-14 的 通信 图 和 图 21-15 
的 顺序 图 。 

«client» 


«subsystem» 
: ATMClient 


«service» 
«subsystem» 


Я i ina М1: Validate PIN V7: Valid PIN 
:BankingService (PIN тте ИВИЋ | ^ (Account #s) 


«business logic» 
: PINValidation 


TransactionManager 


V2: Validat e V6: Li 
(Card ld, PIN) V4: Read ee 
2 一 (Card Id) 4 Л: Account #5 Transaction 


V3: Valid PIN 
«entity» «entity» «entity» 
: DebitCard : CardAccount : TransactionLog 


21-14 通信 图 : 银行 服务 “验证 PIN 45" НИЯ 


«business logic» «entity» ae 
«subsystem: : PINValidation DebitCard ey 
:ATMCIert TransactionManager 
i 
' 
Ц 
I 
' 
Ц 
i 





м Validate PIN 
р (PIN Validation ny | 
一 一 一 一 一 一 一 一 
| 1 V2 Validate | | 
| | (Cardia PIN) | 
1 т 
1 Н H 

р V3: Valid PIN 


t 
1 
V4: Read (Card 4) 1 


П 1 

| tog Toneacton _ К 

| 1 i 1 

і ут: Valid PIN H | р 1 

(Account #8) ! ! 

! ! i Н i 
i Н | 


图 21-15 顺序 图 : 银行 服务 “验证 PIN 码 ” 用 例 
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V1: “АТМ 客户 端 ” 向 “PIN 码 验 证 交易 管理 器 ”发 送 “验证 PING” ik. “PIN 
码 验 证 交易 管理 器 ”中 包含 判断 PIN 码 是 否 有 效 的 业务 逻辑 ， 即 判断 客户 输入 的 PIN 码 
是 否 与 银行 服务 数据 库 中 的 PIN 码 相符 。 

V2 :“PIN 码 验 证 交易 管理 器 ”向 “ 借 记 卡 ” 实 体 对 象 发 送 一 个 “验证 ”( Validate ) 
消息 (包含 “卡号 ”“PIN”)， 要 求 其 根据 卡号 和 客户 输入 的 PIN 码 来 验证 客户 的 借 记 卡 
是 否 有 效 。 

V3 :“ 借 记 卡 ”检查 验证 客户 输入 的 PIN 码 是 否 与 “ 借 记 卡 ” 中 记录 的 PIN 码 符 
合 、 卡 的 状态 是 否 正常 (无 挂失 ) 以 及 该 卡 是 否 过 期 。 如 果 所 有 验证 通过 ,“ 借 记 卡 ”向 
“PIN 码 验证 交易 管理 器 ”发 送 一 个 有 效 PIN 码 的 响应 。 

V4: 如 果 验 证 通过 ,“PIN 码 验 证 交易 管理 器 ”向 “ 卡 账 户 ” 实 体 对 象 发 送 消息 ， 要 
求 其 返回 当前 卡号 可 访问 的 账户 号 。 

V5:“ 卡 账户 ”返回 有 效 的 账户 号 。 

V6:“PIN 码 验 证 交易 管理 器 ”用 “交易 日 志 ”( Transaction Гор) 来 记录 交易 日 志 。 

V7 :“PIN 码 验证 交易 管理 器 ”向 “ATM 客户 端 ” 发 送 一 个 “有 效 PIN 码 ” 的 响应 。 
wR PIN 码 验 证 成 功 ， 还 会 发 送 账户 号 。 





21.5.3 ”客户 端 取款 交互 图 的 消息 序列 描述 


客户 端 “ 取 款 ” 交 互 图 的 消息 序列 描述 了 包括 通信 图 (图 21-16 ) 与 顺序 图 ( 21-17) 
的 消息 ， 也 描述 了 ATM 状态 图 (图 21-18 ) 上 的 相关 状态 和 转移 。 下 面 的 消息 接着 21.5.1 节 
中 客户 端 “验证 PIN 码 ” 交 互 图 的 消息 继续 编号 。 


3: “АТМ 客户 ”参与 者 向 “客户 交互 ”对 象 输入 “取款 ”选项 ， 并 告知 账户 号 〔( 支 
票 账户 和 储蓄 账户 ) 以 及 取款 金额 。 

3.1:“ 客 户 交互 ”对 象 将 客户 选项 发 送 给 “ATM 交易 ”对 象 。 

3.2: “АТМ 交易 ”对 象 将 “取款 交易 ”详细 信息 返回 给 “客户 交互 ”对 和 象 。“ 取 款 交 
易 ” 包 含 了 交易 号 、 交 易 类 型 、 卡 号 、PIN 码 、 账 户 号 和 人 金额。 

3.3 :“ 客 户 交互 ”对 象 将 “选择 取款 ”( Withdrawal Selected) (“取款 交易 ”) 的 请 
求 发 送 给 “ATM 控制 ”对 象 。 接 着 ,“ATM 控制 ”对 象 转移 到 “处 理 取款 ”( Processing 
Withdrawal) 状态 ， 与 该 转移 相关 的 输出 事件 是 “请 求 取款 ”( Request Withdrawal ) 和 
“显示 等 待 ”( Display Wait )。 

3.4: “ATM 控制 ”对 象 向 “银行 服务 ”发 送 一 个 包含 “取款 交易 ”( Withdrawal 
Transaction ) 的 “取款 请 求 交易 ”( Request Withdrawal )。 

3.4а: “АТМ 控制 ”对 象 向 “客户 交互 ”对 象 发 送 “显示 等 待 ”( Display Wait) 的 消息 。 

3.4a.1:“ 客 户 交互 ”对 象 向 “ATM 客户 ”显示 “等 待 提 示 ”( Wait Prompt )。 

3.5:“ 银 行 服务 ”向 “ATM 控 制 ” 对 象 发 送 一 个 “允许 取款 ”( Withdrawal 
Approved) 响应 (包含 取款 “金额 "、“ 余 额 ” 信 息 )。 该 事件 导致 “ATM 控制 ”转移 至 
“分 发 现金 ”( Dispensing ) 状态 。 同 时 ,输出 事件 为 “分 发 现金 ”( Dispense Cash) 以 及 
“更 新 状态 ”。 

3.6: “АТМ 控制 ”对 象 向 “ 吐 钞 器 接口 ”发 送 一 个 “分 发 现金 ”消息 (包含 取款 
“金额 ”信息 )。 
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3.6a : “АТМ 控制 ”对 象 向 “ATM 交易 ”对 象 发 送 一 个 “更 新 状态 ”消息 (包含 取 
“金额 ”、“ 余 额 ” 信 息 )。 

3.7 :“ 吐 钞 器 接口 ”向 “ATM 现金 ”( АТМ Cash) 发 送 一 个 “取款 ”消息 (包含 取 
款 “ 人 金额 ”信息 )。 

3.8: “АТМ 现金 ”向 “ 吐 钞 器 接口 ”发 送 一 个 表示 接受 的 “现金 响应 ”(Cash 
Response )， 明 确 待 分 发 的 每 种 面额 钞票 的 张 数 。 

3.9: 为 了 把 钞票 分 发 给 客户 ,“ 吐 钞 器 接口 ”向 “ 吐 钞 器 ”外 部 输出 设备 发 送 “ 提 
款 机 输出 ”( Dispenser Output ) 命令 。 

3.10:“ 吐 钞 器 接口 ”向 “ATM 控制 ”对 象 发 送 “现金 已 分 发 ”( Cash Dispensed) 的 
消息 。 该 消息 导致 “ATM 控制 ”转移 至 “打印 ”( Printing ) 状态 。 与 该 转移 相关 的 输出 
事件 是 “打印 赁 条 ”、“ 显 示 分 发 现金 ”( Display Cash Dispensed) 以 及 “确认 现金 分 发 ” 
( Confirm Cash Dispensed )。 

3.11 : “ATM 控制 ”对 象 向 “和 任 条 打印 机 接口 ”( Receipt Printer Interface) Rik “Я 
Я Ж” (Print Receipt) 消息 。 

3.11а: “АТМ 控制 ”向 “客户 交互 ”发 送 “显示 分 发 现金 ”消息 。 

3.11a.1:“ 客 户 交互 ”把 “现金 已 分 发 ”提示 显示 给 “ATM 客户 ”。 

3.11b:“ATM 控制 ”向 “银行 服务 ”发 送 一 个 “确认 现金 分 发 ”消息 。 

3.12:“ 和 赁 条 打印 机 接口 ”向 “ATM 交易 ”请 求 交易 数据 。 

3.13: “ATM 交易 ”向 “和 赁 条 打印 机 接口 ”发 送 交易 数据 。 

3.14 :“ 赁 条 打印 机 接口 ”向 “和 赁 条 打印 机 ”外 部 输出 设备 发 送 赁 条 “打印 机 输出 ” 
( Printer Output ) 消息 。 

3.15 :“ 和 赁 条 打印 机 接口 ”向 “ATM 控制 ”发 送 “ 赁 条 已 打印 ”(Receipt Printed) Ж 
息 。 由 此 ,“ATM 控制 ”转移 到 “正在 弹出 卡 ”( Ejecting ) 状态 。 此 时 ， 输 出 事件 是 “ 弹 
出 卡 ”( Eject )。 

3.16: “АТМ 控制 ”向 “ 读 卡 器 接口 ”发 送 “ 弹 出 卡 ” 消 息 。 

3.17 :“ 读 卡 器 接口 ”向 “ 读 卡 器 ”外 部 输入 /输出 设备 发 送 “ 读 卡 器 输出 ”( Card 
Reader Output ) 消息 。 

3.18 :“ 读 卡 器 接口 ”向 “ATM 控制 ”对 象 发 送 “ 卡 弹 出 ”(Card Ejected) 消息 。 
“ATM 控制 ”转移 到 “已 终止 ”(Terminated ) 状态 。 此 时 ， 输 出 事件 是 “显示 卡 已 弹出 ” 
( Display Ejected )。 

3.19: “АТМ 控制 ”对 象 向 “客户 交互 ”对 象 发 送 “ 显 示 卡 已 弹出 ”的 消息 。 

3.20:“ 客 户 交互 ”对 象 向 “ATM 客户 ”显示 “ 卡 已 弹出 ”的 提示 消息 。 





21.5.4 服务 器 端 取款 交互 图 的 消息 序列 描述 


参与 服务 器 端 “ 取 款 ” 用 例 的 业务 逻辑 对 象 是 “取款 交易 管理 器 ”， 该 对 象 封 装 了 确定 
客户 是 否 可 以 从 某 个 账户 中 取款 的 逻辑 。 其 他 参与 服务 器 用 例 的 业务 逻辑 对 象 包括 “转账 交 
易 管 理 顺 ”( 封 疾 了 确定 客户 是 否 能 够 将 资金 从 一 个 账户 转 到 男 一 个 账户 的 逻辑 ) 和 “查询 交 
易 管 理 器 ”"。 后 者 由 于 过 于 简单 ， 所 以 严格 来 说 未 必 有 必要 将 其 封装 为 一 个 独立 的 业务 逻辑 对 
象 ; 其 功能 也 可 以 通过 “账户 ”对 象 的 “ 读 取 ”操作 来 实现 。 然 而 ,为 了 与 其 他 业务 逻辑 对 
象 一 致 ， 此 处 仍然 将 其 作为 一 个 独立 的 业务 逻辑 对 象 。 
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Entry / 
Display Welcome 


After (Elapsed Time) [Closedown not Requested] 


3.18: Card Ejected / 
3.19: Display Ejected 


Ejecting 


3.15: Receipt Printed / 
3.16: Eject 

















Waiting for 
Customer Choice 





3.3: Withdrawal Selected / 
3.4: Request Withdrawal, 
3.4a: Display Wait 


Processing 
Withdrawal 


3.10: Cash Dispensed / 
3.11: Print Receipt, 
3.11a: Display Cash Dispensed, 

3.116: Confirm Cash Dispensed 
3.6; Dispense Cash, 


Dispensing 
3.6a: Update Status 


Н 21-18 “ATM 控制 ”的 状态 图 :“ 取 款 ” 用 例 


我 们 对 服务 器 端 “ 取 款 ” 用 例 做 了 详细 分 析 。 服 务 器 端 “转账 ”用 例 和 “查询 账户 ”用 
例 也 需要 类 似 的 分 析 方 法 。 下 面 的 消息 序列 描述 与 图 21-19 中 的 服务 器 端的 “取款 ”用 例 的 
通信 图 和 图 21-20 中 的 顺序 图 相对 应 。 





3.5: Withdrawal Approved / 





W1: “АТМ 客户 端 ” 向 “取款 交易 管理 器 ”( 其 中 包含 了 确定 是 否 允 许 取款 的 业务 
394 we) 发 送 “取款 请 求 "。 传 入 的 取款 交易 包括 “交易 号 ”"“ 交 易 类 型 “卡号 ”、 “PIN 
а" “账户 号 ”以 及 取款 “金额 ”。 

W2 :“ 取 款 交 易 管 理 器 ”向 “ 借 记 卡 ” 发 送 一 个 “检查 每 日 取款 上 限 ”( Check Daily 
Limit) 消息 (包含 “卡号 ”和 取款 “金额 ”信息 )。“ 借 记 卡 ”检查 该 卡号 是 否 已 经 达到 每 日 
取款 上 限 。“ 借 记 卡 ”人 允许 取款 的 条 件 为 : 当日 已 取款 总 额 + 本 次 取款 金额 三 每 日 取款 上 限 。 

W3 :“ 借 记 卡 ”向 “取款 交易 管理 器 ”响应 一 个 表示 接受 或 拒绝 的 “每 日 上 限 响 应 ” 
(Daily Limit Response )。 

W4 : 如 果 接 受 了 请 求 ,“ 取 款 交 易 管 理 器 ”向 “账户 对 象 ”( 该 对 象 为 “支票 账户 ” 
或 “ 储 鞋 账户 ”的 一 个 实例 ) 发 送 一 条 消息 ， 该 消息 可 以 在 客户 账户 余额 足够 的 情况 下 
取出 相应 的 金额 。“ 账 户 ” 对 象 允 许 取款 的 条 件 为 : 账户 余额 - 请求 取 款 金额 二 0。 如 果 
金额 足够 ,“ 账 户 ” 对 象 就 从 “余额 ”中 减 去 “请 求 取款 金额 ”。 

W5 :“ 账 户 ” 对 象 向 “取款 交易 管理 器 ”返回 “允许 取款 ”( Withdrawal Approved ) 
消息 (包括 取款 “金额 ”和 “余额 ”信息 ) 或 者 “拒绝 取款 ”( Withdrawal Denied) 消息 。 

W6 : 如 果 从 账户 中 成 功 取款 ,“ 取 款 交 易 管 理 器 ” 则 向 “ 借 记 卡 ” 发 送 一 个 “更 新 
每 日 取款 总 额 ”( Update Daily Total) 的 消息 (包含 “卡号 ”和 “金额 ”信息 )， 由 此 可 把 
请 求 的 取款 金额 加 入 当日 取款 总 额 。 

W7:“ 取 款 交易 管理 器 ”将 “交易 日 志 ” 记 入 本 次 交易 信息 。 

W8 :“ 取 款 交 易 管 理 器 ”向 “ATM 客户 端 ” 返 回 “ 人 允许 取款 ”消息 (包括 取款 “人 金 
额 ” 和 “余额 ”信息 ) 或 者 “拒绝 取款 ”消息 。 
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«client 
«subsystem» 
: ATMClient 


«service» 

«subsystem» 

: BankingService 
WI: Request withdrawal | || W8: Withdrawal Approved 

(Withdrawal Transaction) (Amount, Balance) 


«business logic» 
: Withdrawal 
TransactionManager 


ҮҮТ: Log Transaction 


W4: Debit 
он ANOUN (Card Id, Amount), 
(Accounts nt) W6: Update 


Daily Total 
Ра (Card Id, Amount) 
WS: Withdrawal 


Approved 

(Amount, Balance) «entity» 
«entity» «entity» : Transaction 
: Account : DebitCard Log 





Al 21-19 通信 图 : 银行 服务 的 “取款 ”用 例 


«business logic» У «entity» 
«subsystem» : Withdrawal ‚ «епу» «entity» Transat 
: ATMClient Transaction : DebitCard : Account 
Manager 
I 


i 1 ! 
| | | | 
i W1: Request Withdrawal | | 1 
р (Withdrawal! Transaction) | 1 Н 

1 1 
i | W2: Check Daily Limit ! ! 
р (Card Id, Amount) ! 1 
1 一 一 一 > 
| 1 р | 
| i 1 р 
Н W3: Status | | 
р < 

1 

! i П 
| W4: Debit (Account#, Amount) 1 
у : 
1 
! i 
i | 
! П 
1 1 
1 1 
| 1 
1 1 
| | 
| 1 
1 


W5: Withdrawal Approved (Amount, Balance) 


і 

! 

1 

| 

|W6: Update Daily Total 

| (Card Іа, Amount) 1 

raa 

1 . A 
WS: Withdrawal Approved ! W7: Log Transaction 
(Amount, Balance) | 
1 


图 21-20 顺序 图 : 银行 服务 的 “取款 ”用 例 


21.6 ATM 状态 图 


HF “ATM 控制 ”( АТМ Control) 是 一 个 控制 对 象 ， 因 此 需要 为 它 定义 一 个 状态 图 。 在 
图 21-14 和 图 21-18 中 分 别 描 述 了 对 应 于 “验证 PIN 码 ” 和 “取款 ”用 例 的 部 分 状态 图 。 这 
里 也 有 必要 为 其 他 用 例 画 状态 图 ， 并 为 这 些 用 例 的 可 替换 场景 定义 状态 和 转移 ， 由 此 来 覆盖 
异常 情况 。 我 们 一 开始 用 扁平 状态 图 来 描述 这 些 用 例 。 在 第 10 章 中 阐述 了 如 何 将 状态 图 集成 
到 不 同 的 用 例 中 以 及 如 何 设计 具有 层次 结构 的 АТМ 控制 状态 图 。 具 有 层次 结构 的 状态 图 的 一 
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大 好 处 就 是 可 以 像 图 21-21 ~ 图 21-24 中 那样 分 阶段 表示 状态 。 这 些 图 上 的 事件 序列 编号 对 应 
于 此 前 描述 的 对 象 交 互 。 

图 21-21 中 描述 了 一 个 由 5 个 状态 组 成 的 顶层 状态 图 : 初始 的 “关闭 ”( Closed Down ) 
RA, “ZW” (14е) 状态 以 及 3 个 复合 状态 ， 即 “处 理 客 户 输 入 ”( 了 Processing Customer 
Input ) “处 理 交 易 ”( Processing Transaction ) 和 “结束 交易 ”( Terminating Transaction )。 每 
个 复合 状态 可 以 进一步 分 解 为 更 细 粒 度 的 状态 图 ， 如 图 21-22、 图 21-23 和 图 21-24 所 示 。 

在 系统 初始 化 时 ,“ 启 动 ” 事 件 使 得 АТМ 机 从 初始 的 “关闭 ”状态 转移 到 “空闲 ” 状 
态 。 进 入 “空闲 ”状态 的 时 候 会 触发 “显示 欢迎 ”( Display Welcome ) 事件 。 处 于 “空闲 ” 状 
态 的 时 候 ，ATM 机 一 直 等 待 由 客户 触发 的 事件 。 


Closed Down 
Entry / Display 
System Down 

Startup || Closedown 












After(Elapsed Time) 
[Closedown Was Requested] 


















к! (ве мет 
Get PIN [Closedown Not Requested] 
Entry / Display 
Welcome 


Card Stolen, Card Expired/ 
Confiscate, Update Status 




















Processing 
Customer 
Input 














Third Invalid PIN / Confiscate 
Cancel / Eject, 
Display Cancel 


Terminating 
Transaction 


Rejected / 
Eject, 
Display Apology 







Transfer Selected / 
Request Transfer, 
Display Wait 










Transfer Approved 
Print Receipt, 
Update Status 










Query Selected / 
Request Query, Display Wait 









Query Approved / 
Print Receipt, 
Update Status 





Processing 
Transaction 









Withdrawal Selected / 
Request Withdrawal, 
Display Wait 






Withdrawal Approved / 
Dispense Cash, 
Update Status 


Н 21-21 “ATM 控制 ”的 顶层 状态 图 


2161 处理 客户 输入 复合 状态 


“处 理 客户 输入 ”复合 状态 (图 21-22 ) 被 分 解 为 三 个 子 状 态 :“ 等 待 PIN 码 输入 ” 
( Waiting for PIN ) “验证 PIN 码 ”(Validating PIN) 以 及 “等 待 客户 选择 ”( Waiting for 
Customer Choice ): 

1) 等 待 PIN 码 输 入 : 当 客 户 把 卡 插入 АТМ 机 之 后 , АТМ 机 从 “空闲 ”状态 进入 该 子 状态 ， 
从 而 触发 “卡片 插入 ”( Сага Inserted ) 事件 。 在 该 子 状态 下 ，ATM 机 等 待 客户 输入 PIN 码 。 
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Card Inserted / 
Get PIN 










Entry / Display 
Welcome 





Processing 
Customer 
Input 





Cancel / Eject, 


Display Cancel 
Ejecting 


Card Stolen, Card Expired / 
Confiscate, Update Status 





Waiting for 
PIN 

















Invalid PIN / 
Invalid PIN Prompt 


Valid PIN / 
Display Menu, 
Update Status 






PIN Entered/ 
Validate PIN 
























Validating PIN Confiscating 








Third Invalid PIN / 
Confiscate 


Waiting for 
Customer 
Choice Transfer Selected / 
Request Transfer, 
Display Wait 





Withdrawal Selected / 
Request Withdrawal, 
Display Wait 







Query Selected / 
Request Query, 
Display Wait 





Processing Transaction 


a) 










Waiting for 
PIN 


PIN Entered/ 
Validate PIN 


Invalid PIN/ 
Invalid PIN Prompt 


Third Invalid PIN / 
Confiscate 











Invalid PIN/ 
Validating PIN | Update Status 
and Card 





Checking PIN 
Status 








Confiscating 





Card Stolen, Card Expired / 
Confiscate, Update Status 







Valid PIN / 
Display Menu, 
Update Status 


Waiting for 
Customer 
Choice 

b) 


图 21-22 “АТМ 控制 ”的 状态 图 :“ 处 理 客户 输入 ”复合 状态 
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2) 验证 PIN 码 : 当 客户 输入 PIN 码 后 АТМ 机 进入 该 子 状态 。 在 该 子 状 态 下 , “银行 服 
务 ” 验 证 PIN #9. 

3) 等 待 客户 选择 : 在 “有 效 PIN 码 ”( Valid PIN) 事件 发 生 之 后 АТМ 机 进入 该 子 状态 ， 
意味 着 PIN 码 已 经 正确 输入 。 在 该 子 状 态 下 ， 客 户 需要 输入 一 个 选择 : 取款 、 转 账 或 查询 。 

该 状态 图 是 通过 考虑 客户 参与 者 完成 各 用 例 ( 从 “验证 РІМ 码 ” 用 例 开始 ) 时 ATM 机 
的 不 同 状态 开发 出 来 的 。 当 一 个 客户 插入 АТМ 卡 ,“ 卡 片 插入 ”事件 使 得 ATM 机 的 状态 变 
为 “处 理 客 户 输入 ”复合 状态 的 “等 待 PIN 码 输入 ” 子 状态 ( 见 图 21-22a )。 在 此 期 间 ，ATM 
机 一 直 等 待 客户 输入 PIN 码 。 输 出 事件 “获取 PIN 码 ”( Get PIN) 使 客户 看 到 显示 器 上 的 提 
示 。 客 户 输入 РІМ a, “РІМ 码 已 输入 ”( PIN Entered) 事件 使 ATM 机 的 状态 转移 至 “验证 
PIN 码 ” 子 状态 ， 此 时 “银行 服务 ”会 判断 客户 输入 的 PIN 码 是 否 与 “银行 系统 ”中 储存 的 
对 应 卡 的 PIN 码 相 符 。 一 共有 三 个 来 自 “验证 PIN 码 ” 状 态 的 状态 转移 。 如 果 所 输入 的 PIN 
码 正 确 ， 便 可 通过 “有 效 PIN 码 ” 转 移 进 入 “等 待 客户 选择 ”状态 。 如 果 PIN 码 不 正确 ,将 
通过 “无 效 PIN 码 ”( Invalid PIN ) 转移 重新 进入 “等 待 PIN 码 输 入 ”状态 让 客户 重新 输入 
PIN 码 。 如 果 客 户 错误 输入 PIN 码 三 次 ， 将 通过 “第 三 次 错误 输入 PIN 码 ”(Third Invalid ) 
转移 进入 “结束 交易 ”复合 状态 的 “没收 ”( Confiscating ) 子 状 态 。 

“验证 PIN 码 ” 子 状态 本 身 也 是 一 个 复合 状态 ， 由 两 个 子 状态 组 成 :“ 验 证 PIN BAR” 
( Validating PIN and Card ) 以 及 “检查 PIN 码 状 况 ”( Checking PIN Status ) ( 见 图 21-22b )。 在 
前 一 个 子 状态 下 ， 系 统 会 将 ( 从 卡 上 读 出 的 ) 卡号 和 (客户 输入 的 ) PIN 码 与 存储 于 “ 卡 账 
ја" (Сага Account ) 实体 对 象 的 卡号 /PIN 码 相 比较 ， 由 此 验证 客户 输入 的 卡号 与 PIN 码 是 否 
正确 。 此 外 ， 验 证 卡号 可 以 保证 该 卡 未 被 挂失 。 如 果 验 证 通过 ，ATM 机 转移 到 “等 待 客户 选 
择 ” 状 态 。 如 果 卡 已 被 挂失 ,那么 ATM 转移 到 “没收 ”状态 。 然 而 ， 如 果 是 输入 的 РМ 15 
不 正确 ,那么 需要 额外 检查 此 次 输入 是 否 是 第 三 次 错误 的 输入 。 最 好 把 错误 输入 的 计数 存 于 
客户 端 而 非 服务 器 ， 因 为 它 只 是 一 个 АТМ 机 的 局 部 问题 。 因 此 ， 错 误 的 PIN 码 输入 次 数 被 
保存 在 “ATM 交易 ”对 象 中 。 每 当 服务 器 响应 这 是 一 个 错误 PIN 码 输 入 ， 该 计数 就 被 更 新 
一 次 。 如 果 计 数 小 于 三 次 ,那么 ATM 转移 回 “ 等 待 PIN 码 输入 ”状态 。 如 果 计 数 表 明 这 是 
“第 三 次 错误 输入 PIN 码 ”， 那 么 ATM 转移 到 “没收 ”状态 。 

在 任意 一 个 “处 理 客户 输入 ” 子 状态 中 ， 客 户 都 可 以 按 ATM 机 上 的 “取消 ”按钮 。 此 
В}, “HA” (Cancel) 事件 将 ATM 转移 到 “结束 交易 ”复合 状态 的 “弹出 卡 ” 子 状态 。 由 于 
“取消 ”事件 可 能 发 生 在 “处 理 客户 输入 ”复合 状态 的 任意 子 状态 中 ， 因 此 将 “取消 ”转移 画 
在 复合 状态 上 会 显得 更 简洁 。 


21.6.2 ”处 理 交 易 复合 状态 


“处 理 交易 ”复合 状态 ( 图 21-23 ) 也 被 分 解 为 三 个 子 状态 ， 每 个 子 状态 针对 一 种 交易 : 
“Ak ERIK” (Processing Withdrawal )、 “处 理 转账 ”( Processing Transfer) 和 “处 理 查询 ” 
(Processing Query )。 系 统 将 根据 客户 的 选择 ( 例如 取款 ) 进入 “处 理 交易 ”复合 状态 中 相应 
的 子 状态 (例如 “处 理 取款 ”) 以 处 理 客户 的 请 求 。 

在 “等 待 客户 选择 ”状态 下 ， 客 户 可 以 选择 取款 、 查 询 或 者 转账 并 进入 “处 理 交 易 ” 复 
合 状态 中 相应 的 子 状态 ， 例 如 “处 理 取 款 ” 子 状态 ( 见 图 21-23 )。 当 取款 交易 完成 后 ， 如 果 
客户 有 足够 的 资金 ， 那 么 就 会 触发 “人 允许 取款 ”( Withdrawal Approved) 事件 ， 从 而 进入 “ 结 
RAR” BARS “ARMS” TRE ( 见 图 21-24 )。 相 反 ， 如 果 客 户 资金 不 足 或 者 取款 
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金额 超出 每 日 取款 上 限 ， 就 会 触发 一 个 “拒绝 ”( Rejected ) 事件 。 
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Dispense Cash, 
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图 21-23 “АТМ 控制 ”的 状态 图 :“ 处 理 交 易 ” 复 合 状态 
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Display Cash Dispensed, 
Confirm Cash Dispensed 


图 21-24 “ATM 控制 ”的 状态 图 :“ 结 束 交易 ”复合 状态 











Withdrawal Approved / 
Dispense Cash, 
Update Status 







216.3 ”结束 交易 复合 状态 
“结束 交易 ”复合 状态 (МИ 21-24) 的 子 状态 包括 “分 发 现金 ”(Dispensing ) “打印 ” 
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(Printing ), “弹出 卡 ”( Ejecting ) “没收 ”( Confiscating ) 和 “停止 ”( Terminating )。 


与 “分 发 现金 ”状态 的 转移 相关 的 动作 是 “分 发 现金 ”(Dispense Cash ) 和 “更 新 状 
AS” (Update Status )。 当 “现金 已 分 发 ”( Cash Dispensed) 事件 发 生 后 ，ATM 机 转移 到 “ 打 
印 ” 状 态 下 进行 任 条 打印 。 在 该 转移 上 执行 “打印 赁 条 ”( Print Receipt) 动作 。 赁 条 被 打印 
完 后 ， 则 进入 “弹出 卡 ”状态 并 执行 “弹出 卡 ” 动 作 。 当 卡 被 弹出 后 (事件 “ 卡 弹出 ”( Сага 
Ejected ) )， 进 入 “停止 ”状态 。 

如 АМТ 状态 图 所 示 ， 对 于 “查询 ”和 “转账 ”交易 ， 除 了 不 会 分 发 现金 外 ， 交 易 被 允 
许 后 的 状态 变化 序列 都 是 相似 的 。 


21.7 ”银行 系统 的 设计 


接 下 来 ,我们 将 “银行 系统 ”的 分 析 模 型 映射 到 一 个 设计 模型 ， 此 过 程 可 分 为 以 下 步骤 : 
1 ) 集成 通信 模型 ， 开 发 出 集成 的 通信 图 。 

2) 将 “银行 系统 ”分 成 多 个 子 系统 并 定义 子 系统 之 间 的 接口 。 

3 ) 对 每 个 子 系统 ， 将 其 分 解 为 多 个 并 发 任务 。 

4) 对 每 个 子 系统 ， 设 计 信 息 隐藏 类 。 

5 ) 开发 更 加 详细 的 软件 设计 。 


21.8 集成 通信 模型 


由 于 “银行 系统 ”是 一 个 客户 端 /服务 器 系统 (21.4 节 )， 因 此 此 前 我 们 已 经 确定 将 其 
分 为 客户 端 与 服务 子 系统 ， 如 图 21-8 所 示 。 通 信 图 也 相应 地 按照 客户 端 和 服务 子 系统 进行 
了 构造 。 

图 21-11 与 图 21-16 描述 了 客户 端 “ 验 证 PIN 码 ” 用 例 和 “取款 ”用 例 的 通信 图 。 同 样 ， 
客户 端 “ 转 账 ” 用 例 、“ 查 询 账 户 ” 用 例 以 及 由 操作 员 触 发 的 用 例 也 需要 这 样 的 通信 和 图。 如 
第 13 章 所 述 ， 合 并 所 有 基于 用 例 的 通信 图 就 可 以 得 到 “ATM 客户 端 ” 子 系统 的 集成 通信 图 
(图 21-25 )。 为 了 完整 性 ， 集 成 的 通信 图 必须 覆盖 每 个 用 例 的 主 序 列 和 可 替换 序列 。 

一 些 对 象 参与 了 所 有 的 客户 端 通信 ， 如 “ATM 控制 ”; 而 男 一 些 对 象 只 参与 了 部 分 通信 ， 
如 “ 吐 钞 器 接口 ”( Cash Dispenser Interface )。 集 成 通信 图 中 有 些 消 息 是 聚合 消息 ， 如 “客户 
事件 ”( Customer Events ) 和 “显示 器 提示 ”( Display Prompts )。 集 成 的 通信 图 还 必须 包括 第 
13 章 提 到 的 所 有 可 替换 序列 。 因 此 ,“ 没 收 ”( Confiscate ) 和 “ 卡 被 没收 ”( Card Confiscated ) 
消息 来 自 于 描述 客户 交易 失败 的 可 替换 序列 。 与 之 相似 ,“ 显 示 器 提示 ”聚合 消息 包含 了 处 理 
错误 PIN 码 输入 的 消息 、 客 户 账户 金额 不 足 的 消息 等 。 

现在 考虑 “银行 服务 子 系统 ”。 图 21-14 和 21-19 是 服务 器 端 “ 验 证 PIN 码 ” 用 例 和 “ 取 
款 ” 用 例 的 通信 图 。 此 外 ， 服 务 器 端的 “转账 ”用 例 和 “查询 账户 ”用 例 还 需要 额外 的 通 
信 图 。 图 21-26 描述 了 “银行 服务 子 系统 ”的 集成 通信 图 。 每 一 种 交易 都 对 应 一 个 封装 交 
易 业 务 逻 辑 的 交易 管理 器 对 象 ， 包 括 “PIN 码 验 证 交易 管理 器 ”( PIN Validation Transaction 
Manager ) “取款 交易 管理 器 ”( Withdrawal Transaction Manager )、“ 查 询 交易 管理 器 ”( Query 
Transaction Manager ) 和 “转账 交易 管理 器 ”( Transfer Transaction Manager ) 对 象 。 此 外 ,在 
设计 时 还 可 以 确定 此 处 需要 一 个 协调 者 对 象 ， 即 “银行 交易 ”( Bank Transaction ) 协调 者 。 如 
第 15 章 所 述 ， 这 个 协调 者 对 象 用 来 接收 客户 端 请 求 并 将 它们 委托 给 适当 的 交易 管理 器 。 
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K 21-25 “ATM 客户 端 ” 子 系统 的 集成 通信 图 






ATM 
Transactions 







«service» 
«subsystem» 
: BankingService 











«coordinator» 
: BankTransaction 
Coordinator 


PIN Validation 
Request 








«business logic» 
: Query 
Transaction 





«business logic» 
: Transfer 
Transaction 


«business logic» 
: Withdrawal : PINValidation 
Transaction Transaction 
Manager Manager 




















«database 
wrapper» 
: Card 

Account 


«database wrapper» 
: Checking 
Account 


«database 
wrapper» 
: TransactionLog 
















; Savings 
Account 





: DebitCard 








Я 21-26 “银行 服务 子 系统 ”的 集成 通信 图 
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219 将 系统 划分 为 子 系统 


在 “银行 系统 ”的 例子 中 ， 子 系统 划分 步骤 是 显而易见 的 “银行 系统 ”是 一 个 典型 的 基 
于 多 客户 端 / 单 服务 体系 结构 模式 的 客户 端 /服务 器 体系 结构 。 系 统 中 一 共 包 括 两 个 子 系统 : 
拥有 多 个 实例 的 “ATM 客户 端子 系统 ”和 “银行 服务 子 系统 ”， 如 此 前 的 图 21-8 所 示 。 这 两 
个 子 系统 也 可 以 由 图 21-27 所 示 的 高 层 通信 图 来 描述 。 
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21-27 子 系统 设计 :“ 银 行 系统 ”的 高 层 通信 图 


图 21-27 是 一 个 描述 两 个 子 系统 间 简 单 消息 传递 的 分 析 层 面 的 通信 图 。“ATM 客户 端 
子 系统 ”向 “银行 服务 子 系统 ”发 送 “ATM 交易 ”消息 ， 并 得 到 一 个 “银行 响应 ”。“ATM 
交易 ”消息 是 一 个 包含 了 “PIN 码 验 证 ”(PIN Validation), “取款 ”( Withdraw )、“ 查 询 ” 
(Query). “转账 ”( Transfer ) “确认 ”(Confirm ) 以 及 “终止 ”(Abort ) 消息 的 聚合 消息 。 
“银行 响应 ”是 对 这 些 消息 的 各 种 响应 。 

下 一 步 考虑 ATM 应 用 的 分 布 情况 并 定义 分 布 式 消息 接口 。 由 于 这 是 一 个 客户 端 /服务 
器 子 系统 ， 所 以 客户 端子 系统 有 多 个 实例 而 服务 子 系统 有 一 个 实例 。 每 个 子 系统 实例 在 自己 
的 结 点 上 运行 。 在 设计 模型 中 ， 每 个 子 系统 都 是 一 个 包含 至 少 一 个 任务 的 并 发 系统 。 消 息 接 
口 是 带 回复 的 同步 消息 通信 。 每 个 “ATM 客户 端 ” 向 “银行 服务 ”发 送 一 个 消息 然后 等 待 响 
应 。 因 为 “银行 服务 ”会 从 多 个 ATM 客户 端 收 到 消息 ， 因 此 “银行 服务 ”建立 一 个 先进 先 出 
的 消息 队列 来 处 理 到 达 的 消息 。 图 21-28 描述 了 设计 模型 通信 图 。 

接 下 来 考虑 如 何 将 每 个 子 系统 划分 为 多 个 并 发 任务 。 本 章 后 续 各 节 将 首先 考虑 “ATM & 
户 端子 系统 ”的 设计 ， 然 后 是 “银行 服务 子 系统 ”的 设计 。 






21.10 АТМ 客户 端子 系统 的 设计 


要 确定 系统 中 的 任务 ， 就 需要 了 解 应 用 中 各 个 对 象 之 间 的 交互 方式 。 分 析 模 型 的 通信 图 
最 能 阐述 这 一 点 ， 它 描述 了 一 个 给 定 用 例 中 对 象 间 的 消息 传递 顺序 。 对 于 “ATM 客户 端子 
系统 ”， 除 了 该 子 系统 的 集成 通信 图 ， 还 需要 考虑 “客户 验证 РІМ 码 ”( Client Validate РІМ) 
用 例 和 “客户 取款 ”( Client Withdrawal Funds) 用 例 的 通信 图 。 本 节 中 描述 的 任务 设计 将 产 
生 图 21-29 中 所 描述 的 并 发 通信 图 。 
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Я 21-28 子 系统 接口 :“ 银 行 系统 ”的 高 层 并 发 通信 图 
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图 21-29 任务 体系 结构 : 初始 的 “ATM 客户 端子 系统 ”并 发 通信 图 


Information 


21.10.1 设计 ATM 子 系统 并 发 任务 体系 结构 


考虑 支持 “验证 PIN 码 ” 用 例 的 通信 图 ( 见 图 21-11 )。 参 与 交互 的 第 一 个 对 象 是 “ 读 卡 
器 接口 ”( Сага Reader Interface ) 对 象 ， 它 是 一 个 与 真实 读 卡 器 交互 的 输入 /输出 对 象 。“ 读 卡 
器 ”外 部 输入 /输出 设备 是 一 个 事件 驱动 的 输入 /输出 设备 ， 其 特点 是 在 得 到 输入 时 它 会 产生 
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一 个 中 断 。“ 读 卡 器 接口 ”对 象 被 构造 为 一 个 事件 驱动 输入 /输出 任务 ， 如 图 21-29 所 示 。 一 
开始 ， 该 任务 处 于 休眠 状态 。 它 由 中 断 触 发 ,然后 读 取 读 卡 器 输入 并 将 其 转 为 内 部 格式 。 接 
着 它 把 卡 的 内 容 写 到 “ATM 卡 ” 实 体 对 象 上 。 由 于 “ATM 卡 ” 是 一 个 被 动 对 象 ， 所 以 不 需 
要 独立 的 控制 线程 。 该 对 象 进一步 被 归 类 为 一 个 数据 抽象 对 象 。 

“ 读 卡 器 接口 ”任务 然后 向 “ATM 控制 ”发 送 一 个 “卡片 插入 ”( Gard Inserted ) 消息 ， 
“ATM 控制 ”是 一 个 状态 相关 的 控制 对 象 ， 它 执行 “ATM 控制 ”状态 图 。“ATM 控制 ”对 象 
被 构建 为 一 个 状态 相关 的 按 需 驱动 的 控制 任务 ， 这 是 因为 它 需 要 独立 的 控制 线程 来 处 理 不 同 
来 源 的 消息 。 一 开始 ， 它 一 直 处 于 空闲 状态 ， 当 有 包含 控制 请 求 的 消息 到 达 时 它 被 激活 。 收 
到 “卡片 插入 ”消息 后 ,“ATM 控制 ”执行 状态 图 并 转移 到 “等 待 PIN 码 输 入 ” 子 状态 (I 
图 21-21 和 图 21-22 )。 与 该 状态 转移 关联 的 活动 向 “客户 交互 ”发 送 一 个 “获取 PIN 码 ” 消 
息 ,“ 客 户 交 互 ” 是 一 个 与 用 户 交 互 的 对 象 ， 它 在 显示 器 上 输出 消息 并 从 键盘 上 接收 输入 。 
“客户 交互 ”被 构建 为 一 个 事件 驱动 的 用 户 交互 任务 ， 它 拥有 自己 独立 的 控制 线程 。 它 提示 客 
户 输入 PIN 码 、 接 收 PIN E, MA “ATM 卡 ” 读 取 卡 信息 然后 将 卡 和 PIN 码 信息 写 到 “ATM 
交易 ”对 象 上 ,“ATM 交易 ”是 一 个 被 动 的 数据 抽象 对 象 。 由 于 “ATM 卡 ” 对 象 和 “ATM Ж 
易 ” 数 据 抽象 对 象 会 被 许多 任务 访问 ， 所 以 它们 被 放 在 任何 一 个 任务 之 外 。 

ETE, 考虑 支持 “取款 ”用 例 的 通信 图 ， 其 中 包含 了 很 多 “验证 PIN 码 ” 通 信 图 中 的 
对 象 。 不 同 于 “验证 PIN 码 ” 通 信 图 的 对 象 有 “和 赁 条 打印 机 接口 ”( Receipt Printer Interface )、 
“ 吐 钞 器 接口 ”( Cash Dispenser Interface ) LA “АТМ 现金 ”( ATM Cash )。 

外 部 的 “ 吐 钞 器 ”是 一 个 被 动 的 输出 设备 ， 因 此 它 不 需要 一 个 事件 驱动 的 输出 任务 。 故 
而 将 “ 吐 钞 器 接口 ”对 象 作 为 一 个 按 需 驱动 (demand driven) 的 输出 任务 ， 它 会 被 从 “ATM 
控制 ”发 送 来 的 请 求 消息 激活 。 与 之 相似 ,“ 和 凭 条 打印 机 接口 ”对 象 也 被 构建 为 一 个 按 需 驱动 
的 输出 任务 ， 它 会 被 从 “ATM 控制 ”任务 发 送 来 的 请 求 消息 激活 。 

ATM“ 操 作 员 交互 ”用 户 交互 对 象 参与 了 三 个 由 操作 员 引 发 的 用 例 ， 它 也 被 映射 为 一 个 
事件 驱动 的 用 户 交 互 任务 ( 见 图 21-29 )。“ATM 现金 ”实体 对 象 是 一 个 被 动 的 数据 抽象 对 象 ， 
因此 不 需要 独立 的 控制 线程 ， 它 会 被 “ 吐 钞 器 接口 ”和 ATM“ 操 作 员 交 互 ”任务 访问 。 

综 上 所 述 ， 一 共有 一 个 事件 驱动 的 输入 /输出 任务 (“ 读 卡 器 接口 ” )、 一 个 按 需 驱 动 的 状 
态 相 关 控 制 任务 (“ATM 控制 ” )、 两 个 按 需 驱动 的 输出 任务 (“ 吐 钞 器 接口 ”和 “和 赁 条 打印 机 
接口 ”")、 两 个 事件 驱动 的 用 户 交互 任务 (“客户 交互 ”和 ATM“ 操 作 员 交互 ”)。 此 外 ,还 有 三 
个 被 动 实体 对 象 (“ATM E”, “АТМ 交易 ”"、“ATM 现金 " )， 它 们 都 被 归 类 为 数据 抽象 对 象 。 


21.10.2 ЖУ АТМ 子 系统 任务 接口 


为 了 确定 任务 接口 ， 有 必要 分 析 对 象 ( 主动 或 被 动 ) 间 的 交互 方式 。 首 先 ， 考 虑 由 被 动 
数据 抽象 对 象 确定 的 任务 交互 。 在 每 种 情况 下 ， 任 务 会 调用 被 动 对 象 提供 的 操作 。 这 必然 是 
一 个 同步 调用 ， 因 为 操作 处 于 该 任务 的 控制 线程 之 中 。 同 样 地 ， 数 据 抽象 对 象 的 所 有 操作 都 
会 被 同步 调用 。 由 于 每 个 被 动 对 象 都 会 被 多 个 任务 调用 ， 因 此 有 必要 同步 对 这 些 数据 的 访问 。 
在 下 一 节 中 详 述 这 些 被 动 对 象 的 操作 。 

接 下 来 考虑 任务 间 的 消息 交互 。 先 考虑 “ 读 卡 器 接口 ”任务 和 “ATM 控制 ”任务 之 间 的 
接口 。 我 们 希望 “ 读 卡 器 接口 ”向 “ATM 控制 ”发 送 一 个 消息 之 后 不 需要 等 待 消息 被 接收 。 
为 此 ， 需 要 一 个 异步 消息 接口 ， 如 图 21-30 所 示 。 这 意味 着 还 需要 一 个 反 回 的 消息 接口 ， 因 
Ж “АТМ 控制 ” 需 向 “ 读 卡 器 接口 ”任务 发 送 “弹出 ”( Eject ) 和 “没收 ”( Confiscate ) ЇН 
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息 。 我 们 将 此 处 设计 为 一 个 不 带 回复 的 同步 消息 接口 ， 在 向 “ATM 控制 ”发 送 完 消息 之 后 ， 
“ 读 卡 器 接口 ”将 一 直 等 待 “弹出 ”或 者 “没收 ”返回 消息 。 这 意味 着 “ATM 控制 ”可 以 发 
送 一 个 同步 消息 ， 而 不 必 等待 “ 读 卡 器 接口 ”接收 此 消息 。“ 读 卡 右 接口 ”任务 的 响应 是 异步 
的 ， 这 就 提供 了 “ 读 卡 器 接口 ”和 “ATM 控制 ”任务 之 间 最 大 的 灵活 性 。 

考虑 “客户 交互 ”和 “ATM 控制 ”之 间 的 接口 。 应 该 是 异步 还 是 同步 呢 ? 首先 ， 考 虑 一 
个 带 响 应 的 同步 场景 。 "客户 交互 ”向 “ATIM 控制 ”发 送 一 个 “取款 ”请 求 ,“ATM 控制 ” 然 
后 再 向 “银行 服务 ”发 送 交 易 。 在 接收 到 服务 器 的 响应 后 ,“ATM 控制 ”向 “客户 交互 ”发 送 
一 个 显示 器 提示 。 这 种 情况 下 ,“ 客 户 交 互 ”不 可 能 与 客户 进行 交互 ， 因 为 该 对 象 处 于 挂 起 状态 
并 等 待 “ATM 控制 ”的 响应 。 这 从 客户 的 角度 而 言 是 不 合理 的 。 然 后 ， 考 虑 异步 接口 的 方案 ， 
如 图 21-30 所 示 。 按 照 此 方案 ,“ 客 户 交 互 ”向 “ATM 控制 ”发 送 一 个 “取款 ”请 求 而 无 需 等 
待 响应 。 这 样 ， 在 得 到 服务 器 的 响应 之 前 , “客户 交互 ”可 以 对 用 户 的 “取消 ”请 求 做 出 响应 。 
“客户 交互 ”从 “ATM 控制 ”接收 作为 一 个 独立 的 异步 消息 接口 的 响应 。“ 客 户 交 互 ” 被 设计 为 
既 可 以 从 客户 也 可 以 从 “ATM 控制 ” 收 到 消息 的 任务 ， 哪 个 消息 先 来 就 先 处 理 哪 一 个 。 

ATM“ 操 作 员 交互 ”任务 的 接口 也 是 异步 的 。 操 作 员 参与 者 的 请 求 独立 于 客户 请 求 ， 由 
此 ， 从 客户 和 从 操作 员 到 “ATM 控制 ”的 消息 可 以 以 任意 顺序 到 达 。 所 以 ,“ATM 控制 ”用 
一 个 先进 先 出 的 消息 队列 来 处 理 到 达 的 消息 。 

两 个 输出 任务 (“ 吐 钞 器 接口 ”和 “和 赁 条 打印 机 接口 ”) 会 被 从 “ATM 控制 ”到 达 的 请 求 消 
息 激 活 。 在 这 种 情况 下 ， 输 出 任务 在 消息 到 达 之 前 处 于 空闲 状态 ， 因 此 可 以 采用 同步 接口 ， 
为 它 不 会 阻碍 “ATM 控制 ”的 运行 。 在 图 21-30 中 ， 我 们 更 新 了 并 发 交互 图 来 显示 任务 接口 。 


21.10.3 设计 ATM 客户 端 信息 隐藏 类 


“银行 系统 ”中 的 对 象 和 类 最 初 是 在 分 析 模 型 中 确定 的 。 在 设计 过 程 中 可 以 进一步 对 被 动 
类 进行 划分 ， 例 如 实体 类 可 以 被 进一步 划分 为 数据 抽象 类 或 数据 库 包 装 器 类 。 在 设计 类 的 过 
程 中 还 要 设计 类 的 接口 ， 如 第 14 章 所 述 。 为 了 确定 类 接口 ， 有 必要 考虑 通信 图 中 对 象 相互 之 
间 是 如 何 交互 的 。 

首先 ， 考 虑 “ATM 客户 端子 系统 ”中 实体 类 的 设计 。 由 于 “ATM 客户 端子 系统 ”中 没 
有 数据 库 ， 所 有 的 实体 类 都 是 封装 自己 的 数据 ， 因 此 可 以 被 进一步 归 类 为 数据 抽象 类 。 “АТМ 
客户 端子 系统 ”有 三 个 数据 抽象 类 :“ATM F”, “АТМ 交易 ”和 “ATM 现金 "。 数 据 抽象 类 
的 属性 在 实体 类 的 概念 静态 建 模 中 确定 ， 如 第 21.3 节 所 述 。 通 过 分 析 这 些 类 在 交互 图 中 的 使 
用 方式 可 以 确定 这 些 类 的 操作 。 

在 第 14 章 中 已 经 描述 了 “ATM 现金 ”类 和 “ATM 卡 ” 类 的 设计 。 对 于 “ATM 交易 ”类 ， 
它 的 属性 由 静态 模型 确定 ,但 它 的 操作 是 根据 其 他 对 象 访问 该 类 的 方式 确定 的 ,访问 方式 已 在 
通信 图 中 给 出 。 该 类 的 操作 有 “更 新 客户 信息 ”( update Customer Information )、“ 更 新 客户 选择 ” 
( update Customer Selection ) “更 新 PIN 码 状 态 ”(update PIN Status )、 “更 新 交易 状态 ”( update 
Transaction Status) 以 及 “ 读 取 ”( read )。 前 两 个 操作 由 “客户 交互 ”任务 调用 。 接 下 来 两 个 操 
YER “АТМ 控制 ”任务 调用 。“ 赁 条 打印 机 接口 ”任务 在 打印 赁 条 之 前 调用 “ 读 取 ” 操 作 。 

还 有 一 个 状态 机 类 ， 即 “ATM 状态 机 ”( ATM State Machine) 类 ， 它 处 于 “ATM 控制 ” 
任务 之 内 并 封装 了 ATM 状态 图 ， 该 类 被 实现 为 一 个 状态 转移 表 。 它 的 操作 包括 “处 理事 件 ” 
( process Event ) 和 获取 “当前 状态 ”( current State )， 这 些 都 是 状态 机 类 的 标准 操作 。 

图 21-31 详细 描述 了 类 的 设计 ， 包括 了 类 的 属性 和 操作 。 
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21.11 银行 服务 子 系统 的 设计 


由 于 银行 服务 器 拥有 “银行 系统 ”的 中 央 数 据 库 ， 因 此 我 们 通过 考虑 与 静态 模型 相关 
的 重要 设计 决策 来 开始 “银行 服务 子 系统 ”的 设计 。 实 体 类 的 概念 静态 模型 ( 见 图 21-4 一 图 
21-7) 包含 了 几 个 存在 于 银行 服务 器 的 实体 类 。 我 们 做 出 如 下 设计 决策 : 在 服务 器 的 实体 类 
(同样 也 是 原先 在 问题 域 的 静态 模型 中 所 描述 的 实体 类 ) 需要 被 存储 为 关系 数据 库 中 的 关系 
表 。 故 而 在 设计 时 我 们 确定 服务 器 的 实体 类 不 封装 任何 数据 ， 而 是 封装 针对 关系 数据 库 的 接 
口 ， 它 们 本 质 上 是 数据 库 包 装 器 类 。 在 下 一 节 中 详 述 数据 库 包 装 器 类 的 设计 以 及 实体 类 模型 
到 关系 数据 库 的 映射 。 


21.11.1 设计 银行 服务 子 系统 并 发 任务 体系 结构 


现在 考虑 “银行 服务 子 系统 ”的 设计 。 我 们 决定 使 用 一 个 顺序 性 服务 。 只 要 服务 器 的 处 
理 能 力 足 够 大 ， 这 样 的 设计 就 没有 问题 。 在 一 个 顺序 性 服务 中 ， 服 务 被 设计 为 一 个 任务 ， 即 
设计 为 只 有 一 个 控制 线程 的 程序 。 这 种 顺序 性 服务 在 一 个 先进 先 出 的 消息 队列 上 处 理 每 个 交 
易 ， 前 一 个 交易 处 理 完 后 下 一 个 交易 才能 开始 。 

我 们 将 “银行 服务 子 系统 ”设计 为 一 个 顺序 性 服务 任务 ， 并 按 需 激活 运行 。 该 任务 中 包 
括 协调 者 对 象 (“银行 交易 协调 者 ”)、 业 务 逻 辑 对 象 (“PIN 码 验 证 交易 管理 器 “取款 交易 
管理 器 "、“ 查 询 交 易 管 理 器 ”以 及 “转账 交易 管理 器 ”)， 以 及 实体 对 象 ( 可 以 被 进一步 归 类 
为 数据 库 包 装 器 类 )。 服 务 子 系统 的 初始 任务 设计 只 包含 一 个 任务 ， 如 图 21-32 所 示 。 
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图 21-32 “银行 服务 子 系统 ”的 初始 并 发 通信 图 
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“银行 交易 协调 者 ”任务 接收 到 达 的 交易 消息 并 做 出 响应 。 它 委托 交易 管理 器 处 理 交易 ， 
而 交易 管理 器 随后 再 访问 数据 库 包 装 器 类 。“ 银 行 服务 子 系统 ”内 部 的 所 有 交互 都 是 同步 的 ， 
这 与 下 文 所 述 的 操作 调用 相对 应 。 


21.11.2 设计 银行 服务 信息 隐藏 类 


第 15 章 阐 述 了 数据 库 包装 器 类 的 设计 以 及 如 何 从 分 析 模 型 的 实体 类 映射 到 设计 模型 的 
数据 库 包装 器 类 和 关系 数据 库 的 关系 表 ( 扁平 文件 )。 在 “银行 服务 ”中 ， 数 据 库 包装 器 类 
包括 “账户 ”( Account )、“ 支 票 账户 ”( Checking Account), “储蓄 账户 ”( Savings Account )、 
“ 借 记 卡 ”( Debit Сага), “FRIKA” (Сага Account) 以 及 “交易 日 志 ”( Transaction Log )， 如 
图 21-33 所 示 。 每 个 类 都 封装 了 表示 数据 库 中 关系 的 接口 。 从 数据 库 的 角度 来 看 ， 一 个 关系 
数据 库 仅 包含 扁平 文件 ， 并 不 支持 类 层次 结构 ， 因 此 “账户 ”的 泛 化 / 特 化 层次 结构 也 相应 
被 扁平 化 ， 故 而 “账户 ” 父 类 的 属性 在 “支票 账户 ”与 “储蓄 账户 ”中 都 存在 〈 如 第 15 章 所 
述 )。 然 而 ， 对 于 “银行 服务 ”中 数据 库 包装 器 类 的 设计 ,“ 上 账户 ”的 泛 化 / 特 化 层次 结构 需 
要 保留 ， 从 而 使 “支票 账户 ”和 “储蓄 账户 ”数据 库 包装 器 类 继承 抽象 的 “账户 ” 父 类 的 泛 
化 操作 。 


«database wrapper» 
TransactionLog 


«database wrapper» 
CardAccount 


+ read (іп сагаір, out accountNumber) 
+ update (in cardID, in accountNumber) 







«database wrapper» 
DebitCard 





+ read (out transaction) 
+ log (in transaction) 


+ create (cardID) 

+ validate (in сага! , in PIN, out status) 
+ updatePIN (сага О, PIN) 

+ checkDailyLimit (cardID, amount) 





+ updateDailyTotal (cardID, amount) 
+ updateExpirationDate (cardID, 
expirationDate) 
+ updateCardStatus (саг О, status) 
+ updateDailyLimit (cardID, newLimit) 
+ clearTotal (сага О) 
+ read (in саг О, out PIN, 
out expirationDate, out status, 
out limit, out total) 
+ delete (сага! 2) 


«database wrapper» 
Account {abstract} 


+ readBalance (accountNumber) : Кеа | 
+ credit (accountNumber, amount){abstract}| 
+ debit (accountNumber, amount){abstract} 
+ open (accountNumber ) 

+ close (accountNumber) 






















«database wrapper 
CheckingAccount 


+ credit (accountNumber, amount) 


«database wrapper» 
SavingsAccount 


+ debit (accountNumber, account) 


+ readLastDepositAmount + clearDebitCount (accountNumber) 
(accountNumber) : Real 3 + addinterest (accountNumber, 
interestRate) 


+ readCumulativeinterest 
(accountNumber) : Real 


图 21-33 ”银行 服务 的 数据 库 包装 器 类 
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还 需要 设计 四 个 业务 逻辑 类 的 接口 ， 它 们 是 “PIN 码 验 证 交易 管理 器 ”"、“ 取 款 交易 管理 
器 ”““ 查 询 交 易 管理 器 ”以 及 “转账 交易 管理 器 ”， 如 图 21-34 


所 示 。 每 个 交易 管理 器 都 处 理 一 种 原子 交易 。 例 如 ,“ 取 款 交 易 
管理 器 ”提供 了 一 个 “取款 ”操作 ， 在 处 理 客 户 取款 请 求 时 会 
调用 该 操作 。 当 一 个 “ATM 客户 端 ” 对 象 确认 现金 已 分 发 给 客 
户 时 会 调用 “确认 ”操作 。 当 一 个 “ATM 客户 端 ” 对 象 终止 交 
易 时 会 调用 “终止 ”操作 ， 这 种 情况 可 能 是 提 款 机 分 发 现金 失 
败 ， 也 可 能 是 客户 取消 了 交易 。 


21.11.3 ”设计 银行 服务 接口 


“银行 服务 ”是 只 有 一 个 控制 线程 的 顺序 性 服务 子 系统 。 在 
这 一 阶段 ， 尤 其 需要 考虑 “银行 服务 ”任务 的 设计 。 该 任务 是 
一 个 由 被 动 对 象 组 成 的 复合 任务 。"“ 银 行 交易 协调 者 ”对 象 接收 
到 达 的 交易 并 将 它们 委托 给 业务 逻辑 对 象 ， 即 “PIN 码 验 证 交 
易 管理 器 "、“ 取 款 交 易 管 理 器 "、“ 查 询 交易 管理 器 ”以 及 “ 转 
账 交易 管理 器 ”。 

“银行 交易 协调 者 ”对 象 从 “ATM 客户 端 ” 以 先进 先 出 的 
方式 处 理 消息 队列 。 对 每 个 消息 ， 该 对 象 确定 交易 的 类 型 ， 然 
后 委托 相应 的 交易 管理 器 处 理 交 易 。 当 交易 处 理 结 束 后 ， 交 易 
管理 器 会 向 “银行 交易 协调 者 ”发 送 响 应 消息 ， 进 而 再 由 “ 银 
行 交 易 协调 者 ”向 “ATM 客户 端 ” 发 送 响 应 消息 。 以 上 步骤 结 
束 后 ,“ 银 行 交易 协调 者 ”再 处 理 下 一 个 交易 消息 。 

图 21-32 显示 了 “银行 服务 子 系统 ”的 初始 设计 。 在 “ 银 
行 服务 ”的 初始 并 发 通信 图 中 ， 所 有 的 接口 都 是 简单 消息 。 图 
21-35 显示 了 “银行 服务 子 系统 ”并 发 通信 图 的 最 终 版 本 。 多 
个 ATM 客户 端的 实例 与 “银行 服务 ”之 间 进 行 带 回 复 的 同步 通 























«business logic» 
QueryTransactionManager 


+ initialize () 
+ query (in accountNumber, 
out q_response) 






«business logic» 
TransferTransactionManager 


+ initialize () 
+ transfer (in fromAccountNumber, 
їп toAccountNumber, In amount, 
out t_response) 


«business logic» 
PinValidationTransactionManager 


+ initialize () 
+ validatePIN (in сага! , in PIN, 
out v_response) 










«business logic» 
WithdrawalTransactionManager 


+ initialize () 

+ withdraw (in accountNumber, in amount, 
out w_response) 

+ confirm (accountNumber, amount) 

+ abort (accountNumber, amount) 


“银行 服务 ”的 
业务 逻辑 类 


图 21-34 


信 。 “银行 服务 ”内 部 的 所 有 交互 都 只 存在 于 被 动 对 象 之 间 ; 因此 ， 所 有 的 内 部 接口 都 用 操作 


调用 来 定义 (用 同步 消息 表示 法 来 表示 )。 
21.12 关系 数据 库 设计 


本 节 从 概念 实体 类 模型 (如 21.3.3 节 所 述 以 及 图 21-4 ~ 图 21-7 所 描述 ) 开始 来 介绍 银行 关 
系数 据 库 的 逻辑 设计 。 类 图 中 描述 的 所 有 实体 类 ( 图 21-4) 都 存在 于 银行 服务 器 之 中 。 由 于 这 
些 实体 类 的 数据 要 被 持久 化 ， 因 此 它们 需要 被 存储 在 数据 库 中 。 如 21.12 节 所 述 ， 实 体 类 被 设计 
为 数据 库 包装 器 类 ， 而 实体 类 的 内 容 ( 由 实体 类 的 属性 所 定义 ) 需要 保存 在 数据 库 中 的 关系 表 


中 。 在 下 面 的 描述 中 ,我 们 用 下 划 线 表示 主键 ， 用 斜体 表示 外 键 。 


根据 静态 模型 来 设计 关系 数据 库 的 指导 原则 已 在 15.5 节 中 介绍 。 现 在 考虑 图 21-4 中 的 实 
体 类 。“ 银 行 ”( Bank )、“ATM 信息 ”( ATM Info), “X” (Customer) 以 及 “ 借 记 卡 ”( Debit 
Card ) 这 些 实体 类 都 会 被 映射 为 一 个 关系 表 。 对 于 每 张 表 ， 能 用 来 唯一 确定 表 中 某 一 行 的 属性 
就 作为 主键 ， 如 “客户 ” 表 的 主键 customerId( 客户 号 )。 而 外 键 则 被 用 来 实现 表 与 表 之 间 的 导航 。 
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对 于 “账户 ” 泛 化 / 特 化 层次 结构 ， 我 们 决定 通过 将 “账户 ”( Account ) 父 类 的 属性 放 
在 “支票 账户 ”( Checking Account) 与 “储蓄 账户 ”( Savings Account) 表 中 来 实现 层次 结 
构 的 扁平 化 。 虽 然 账户 类 型 ( 储蓄 账户 或 者 支票 账户 ) 是 “账户 ”类 的 一 个 属性 ， 但 是 我 们 
假定 知道 “账户 号 ”后 可 以 确定 账户 类 型 ， 因 此 “支票 账户 ”和 “储蓄 账户 ” 表 的 主键 是 
accountNumber ( 账户 号 )。 与 之 相关 联 的 “ 卡 账 户 ” 类 (在 图 21-4 中 定义 ) 被 设计 为 一 张 关 
联 表 ， 用 来 表示 “ 卡 ” 和 “账户 ”之 间 的 多 对 多 关系 。“ 客 户 账户 ”也 被 设计 为 一 张 关联 表 ， 
用 来 表示 “客户 ”和 “账户 ”之 间 的 多 对 多 关系 。 即 使 在 静态 模型 中 没有 “客户 账户 ”这 样 
一 个 关联 类 ( 因为 АТМ 交易 中 并 不 需要 它 )， 在 关系 数据 库 中 也 需要 这 样 一 张 表 。 

对 于 “ATM 交易 ” 泛 化 / 特 化 层次 结构 ， 我 们 对 其 进行 扁平 化 处 理 ， 但 只 提供 交易 子 类 的 关 
系 表 。 一 个 AIM 交易 的 主键 是 交易 号 ， 它 由 多 个 字段 的 复合 主键 组 成 ， 包 括 : bankld ( 银行 号 )、 
ATMId (АТМ 号 )、date (日 期 )、time (时 间 ), bankld 和 ATMId 也 是 外 键 ， 因为 由 它们 可 以 导航 
到 “银行 ” 表 和 “ATM УМНА” же “АТМ 机 信息 ”有 一 个 复合 主键 ， 由 bankld 和 ATMId 组 成 ， 
其 中 bankld 也 是 一 个 外 键 。 日 期 和 时 间 属 性 可 以 提供 一 个 时 间 截 来 唯一 确定 一 笔 交 易 。 


Bank (bankName, bankAddress, bankId) 

Customer (customerName, customer Id, customerAddress) 

Debit Card (cardId, PIN, startDate, expirationDate, status, limit, total, 
customerld) 

Checking Account (accountNumber, accountType, balance, 
lastDepositAmount) 

Savings Account (accountNumber, accountType, balance, interest) 

Card Account (cardId, accountNumber) 


Customer Account (customerld, accountNumber) 
ATM Info (Бана, ATMId, ATMLocation, ATMAddress) 


Withdrawal Transaction (bankId, ATMId, date, time, transactionType, cardId, 











PIN, accountNumber, amount, balance) 

Query Transaction (bankId, ATMId, date, time, transactionType, cardId, PIN, 
accountNumber, balance) 

Transfer Transaction (bankld, АТМЛа, date, time, transactionType, cardId, PIN, 
fromAccountNumber, toAccountNumber, amount) 

PIN Validation Transaction (bankld, ATMId, date, time, transactionType, 
саг Та, PIN, startDate, expirationDate) 





21.13 ”银行 系统 的 部 署 


由 于 这 是 一 个 客户 端 /服务 器 系统 ， 所 以 客户 端子 系统 有 多 个 实例 而 服务 子 系统 只 有 一 
个 实例 。 如 图 21-36 的 部 署 图 所 示 ， 每 个 子 系统 实例 在 自己 的 结 点 上 运行 。 因 此 ， 每 个 ATM 
客户 端 实例 在 ATM 结 点 上 运行 , “银行 服务 ”实例 在 服务 器 结 点 上 运行 。 


:BankingService 
{1 server node} 


«wide area network» 


: ATMClient : ATMClient : ATMClient 
{1 node per ATM} {1 node per ATM} {1 node per ATM} 


Е 21-36 “银行 系统 ”的 部 署 图 
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21.14 ”其 他 设计 考虑 


另 一 个 设计 决策 是 将 “银行 服务 ”设计 为 一 个 并 发 服务 ， 其 中 “银行 交易 协调 者 ”和 每 
个 业务 逻辑 对 象 都 设计 为 独立 的 按 需 驱动 、 按 需 激活 的 任务 。 根 据 这 种 并 发 服务 设计 ,“ 银 行 
交易 协调 者 ”委托 业务 逻辑 对 象 处 理 一 个 交易 请 求 后 马上 处 理 下 一 个 请 求 ， 由 此 服务 器 可 以 
同时 处 理 多 个 交易 请 求 。 当 顺序 性 服务 设计 不 足以 应 对 交易 的 负载 量 时 应 该 采取 这 种 办 法 。 
关于 更 多 的 并 发 服务 设计 的 信息 请 参阅 第 15 章 。 


21.15 详细 设计 


我 们 用 任务 事件 顺序 逻辑 (task event sequencing logic ) 来 描述 “银行 系统 ”的 详细 设计 。 
在 第 18 章 中 已 给 出 了 “ATM 客户 端子 系统 ”中 “ 读 卡 器 接口 ”任务 和 “ATM 控制 ”任务 的 
行为 规约 以 及 “银行 服务 子 系统 ”中 “银行 服务 ”任务 的 行为 规约 。 本 节 描 述 这 些 任务 的 事 
件 顺序 逻辑 。 


21.15.1 读 卡 器 接口 任务 的 事件 顺序 逻辑 示例 


“ 读 卡 器 接口 ”任务 ( 见 图 21-30) 会 被 一 个 外 部 读 卡 器 事件 唤醒 ， 接 着 读 取 “ATM F” 
(ATM Сага) 输入 、 将 卡 内 容 写 人 “ATM 卡 ” 对 象 、 向 “ATM 控制 (ATM Control) 发 送 一 
个 “卡片 插入 ”( cardInserted ) 消息 ， 然 后 等 待 消息 。 如 果 “ATM 控制 ”发 送 回 来 的 消息 是 
“弹出 卡 ”， 那 么 就 弹出 АТМ F; 如 果 发 送 回来 的 消息 是 “没收 >， 那么 就 没收 卡 。 被 动 的 数 
据 抽象 对 象 “ATM 卡 ” 处 于 任务 之 外 ， 用 于 保存 卡 的 内 容 。 

“银行 系统 ”中 的 所 有 消息 通信 都 是 通过 调用 操作 系统 来 完成 的 。 因 此 ,“ 读 卡 器 接口 ” 
任务 (生产 者 ) ЯП “АТМ 控制 ”( 消费 者 ) 之 间 的 消息 队列 ATMControlMessageQ НЕ 
统 提供 ， 而 “ATM 控制 ”和 “ 读 卡 器 接口 ”任务 之 间 的 同步 通信 也 是 如 此 ( 见 图 21-32 )。 一 
个 名 为 cardReaderMessageBuffer 的 消息 缓存 接收 来 自 “ATM 控制 ”的 同步 消息 。 


Initialize card reader; 
loop 
一 等 待 来 自 读 卡 器 的 外 部 中 断 
wait (cardReaderEvent); 
Read card data held on card’s magnetic strip; 
if card is recognized 
then -- 将 卡 数据 写 到 ATM 卡 对 象 中 
ATMCard.write (cardID, startDate, expirationDate); 
一 向 ATM 控 制 对 象 发 送 卡 已 插入 的 消息 
send (ATMControlMessageQ, cardInserted); 
一 等 待 来 自 ATM 控 制 的 消息 
receive (cardReaderMessageBuffer, message); 
if message = eject 
then 
Eject card; 
一 向 ATM 控 制 对 象 发 送 卡 已 弹出 的 消息 
send (ATMControlMessageQ, cardFjected); 
elseif message = confiscate 
then 
Confiscate card; 
一 向 ATM 控 制 对 象 发 送 卡 已 没收 的 消息 
send (ATMControlMessageQ, cardConfiscated); 
else error condition; 
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end if; 
else 一 未 能 识别 卡 ， 因 此 弹出 
Eject card; 
end if; 
end loop; 


21.15.2 АТМ 控制 任务 的 事件 顺序 逻辑 示例 


“ATM 控制 ”任务 处 于 “ATM 客户 端 ” 子 系统 的 核心 部 分 ( 见 图 21-30 )， 它 与 其 他 
任务 保持 交互 。 “АТМ 控制 ”有 一 个 名 为 ATMControlMessageQ 的 输入 消息 队列 ， 从 那里 
接收 来 自 三 个 生产 者 (“ 读 卡 器 接口 " “客户 交互 ”、ATM“ 操 作 员 交互 ”) КАН. “АТМ 
控制 ”向 一 些 任务 发 送 消 息 。 它 向 “ 读 卡 器 接口 ”发 送 不 带 回 复 的 同步 消息 ， 向 “ 吐 钞 
器 接口 ”和 “和 赁 条 打印 机 接口 ”任务 发 送 带 回 复 的 同步 消息 ， 向 “客户 交互 ”任务 的 
promptMessageQueue 消息 队列 发 送 异 步 消息 ， 向 “银行 服务 ”发 送 带 回复 的 同步 消息 。 

由 于 “ATM 控制 ”任务 是 状态 相关 的 ， 因 此 它 并 不 直接 处 理 到 达 的 事件 而 是 执行 状态 
图 中 定义 的 状态 相关 的 动作 。“ATM 状态 机 ”对 象 中 封装 了 状态 图 的 实现 ， 该 对 象 嵌 套 在 
“ATM 控制 ”中 。 当 新 的 事件 发 生 时 ,“ 处 理事 件 ” 操 作 返 回 待 执行 的 活动 。 在 “ATM 控制 ” 
输入 消息 队列 中 可 接收 大 多 数 事件 ,但 有 三 个 例外 。 由 于 与 “银行 服务 ”的 通信 和 是 同步 的 ， 
因此 来 自 “ 银 行 服务 ”的 响应 是 作为 send 消息 的 输出 参数 收 到 的 。 由 于 与 “ 吐 钞 器 接口 ”和 
“ 赁 条 打印 机 接口 ”任务 的 通信 也 是 同步 的 ， 因 此 “分 发 现金 ”和 “打印 赁 条 ”动作 是 带 回复 
的 同步 消息 ， 返 回 相 应 的 分 发 动作 和 打印 动作 是 否 成 功 的 布尔 值 。 

当 同 步 消息 的 响应 产生 了 新 的 内 部 事件 时 ， 我 们 会 将 newEvent 变量 设 为 该 事件 的 值 并 
将 布尔 变量 outstandingEvent 设 为 True。 该 内 部 事件 的 一 个 例子 是 withdrawalResponse ( 可 
能 同时 出 现 多 个 同步 响应 ， 在 下 一 节 “ 银 行 服务 ”的 事件 顺序 逻辑 中 会 阐述 这 种 情况 ) 和 
cashDispensed。 下 面 是 描述 了 大 部 分 由 “ATM 控制 ”所 执行 的 动作 的 事件 顺序 逻辑 。 执 行 每 
个 动作 后 ， 下 一 步 会 跳 转 到 伪 代 码 case 代码 块 的 底部 (为 了 描述 简洁 ， 伪 代码 中 并 未 明确 写 
出 这 种 跳 转 )。 “АТМ 控制 ”任务 的 伪 代 码 如 下 : 


loop 
一 来 自 所 有 发 送 者 的 消息 都 通过 消息 队列 接收 
Receive (ATMControlMessageQ, message); 
一 抽取 事件 名 称 和 所 有 消息 参数 
一 针对 收 到 的 事件 ， 查 询 状态 转移 表 
-根据 需要 改变 状态 ， 返 回 将 要 执行 的 动作 
newEvent = message.event 
outstandingEvent = true; 
while outstandingEvent do 
ATMStateMachine.processEvent (in newEvent, out action); 
outstandingEvent = false; 
一 执行 ATM 控 制 状态 图 中 定义 的 动作 
case action of 
Get PIN: -- 提示 PIN 码 
send (promptMessageQueue, displayPINPrompt); 
Validate PIN: — 通过 银行 服务 验证 客户 所 输入 的 PIN 码 
send (Banking Service, in validatePIN, out 
validationResponse); 
newEvent = validationResponse; outstandingEvent = true; 
Display Menu: ~ 向 客户 显示 选择 菜单 
send (promptMessageQueue,displayMenu); 
ATMTransaction.updatePINStatus (valid); 
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Invalid PIN Action: -- 显示 非法 PIN 码 的 提示 
send (promptMessageQueue, displayInvalidPINPrompt); 
ATMTransaction.updatePINStatus (invalid); 
Request Withdrawal: -- 向 银行 服务 发 送 取 款 请 求 
send (promptMessageQueue, displayWait); 
send (Banking Service, in withdrawalRequest, out 
withdrawalResponse); 
newEvent = withdrawalResponse; outstandingEvent = true; 
Request Query: — 向 银行 服务 发 送 查 询 请 求 
send (promptMessageQueue, displayWait); 
send (Banking Service, in queryRequest, out queryResponse); 
newEvent = queryResponse; outstandingEvent = true; 
Request Transfer: -- 向 银行 服务 发 送 转账 请 求 
send (promptMessageQueue, displayWait); 
send (Banking Service, in transferRequest, out 
transferResponse); 
newEvent = transferResponse; outstandingEvent = true; 
Dispense: — 分 发 现金 并 更 新 交易 状态 
ATMTransaction.updateTransactionStatus (withdrawalOK); 
send (cashDispenserInterface, in cashAmount, out dispenseStatus); 
newEvent = cashDispensed; outstandingEvent = true; 
Print: — 打印 赁 条 并 向 银行 服务 发 送 确 认 
send (promptMessageQueue, displayCashDispensed); 
send (Banking Service, in confirmRequest); 
send (receiptPrinterInterface, in receiptInfo, out 
printStatus); 
newEvent = receiptPrinted; outstandingEvent = true; 
Eject: — 弹出 ATM 卡 
send (cardReaderInterface, eject); 
Confiscate: 一 没收 ATM 卡 
send (cardReaderMessageBuffer, confiscate); 
ATMTransaction.updatePINStatus (status); 
Display Ejected: 一 显示 卡 被 弹出 的 提示 
send (promptMessageQueue, displayEjected); 
Display Confiscated: -- 显 示 卡 被 没收 的 提示 
send (promptMessageQueue, displayConfiscated); 


end case; 
end while; 
end loop; 


21.15.3 ”银行 服务 任务 的 事件 顺序 逻辑 示例 


“银行 服务 ”从 所 有 的 АТМ 客户 端 接收 消息 ( 见 图 21-36 )。 虽 然 它们 之 间 的 通信 方式 是 
带 回 复 的 同步 通信 ,“ 银 行 服务 ” 仍 需 建立 一 个 消息 队列 ， 因 为 它 需 要 接收 来 自 于 多 个 客户 端 
的 消息 。 在 这 个 顺序 性 解决 方案 中 ,“ 银 行 服务 ”是 一 个 顺序 性 服务 任务 ， 它 处 理 完 一 个 请 求 
后 才能 处 理 下 一 个 请 求 。 


loop 
receive (ATMClientMessageQ, message) from Banking Service Message Queue; 
Extract message name and message parameters from message; 
case Message of 
Validate PIN: 
一 验证 ATM 卡 是 否 合法 以 及 客户 所 输入 的 PIN 码 是 否 与 服务 器 记录 相 匹 配 
PINValidationTransactionManager.ValidatePIN 
(in CardId, in PIN, out validationResponse); 
一 如 果 验 证 成 功 ， 那 么 验证 响应 是 合法 并 且 返 回 当前 借 记 卡 可 以 访问 的 账户 号 
一 否则 验证 响应 是 非法 
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reply (ATMClient, validationResponse); 
Withdrawal: 
一 检查 是 否 超过 每 日 取款 上 限 以 及 客户 账户 中 是 否 有 足够 的 资金 来 满足 请 求 
一 如 果 所 有 检查 都 通过 了 ， 那 么 将 取款 记 入 账户 
WithdrawalTransactionManager.withdraw 
(in AccountNumber, in Amount, out withdrawalResponse); 
一 如 果 通 过 ,那么 取款 响应 是 
— {successful, amount, currentBalance}; 
一 否则 取款 响应 是 {unsuccessful}; 
reply (client, withdrawalResponse); 
Query: 
一 读 取 账 户 余额 
queryTransactionManager.query 
(in accountNumber, out queryresponse); 
-查询 响应 包括 当前 余额 、 最 后 一 次 存款 金额 (支票 账户 ) 或 利息 ( 储蓄 账户 ) 
reply (client, queryResponse); 
Transfer: 
一 检查 客户 的 转 出 账户 中 是 否 有 足够 的 资金 来 满足 本 次 请 求 
一 如 果 通 过 ， 那 么 从 转 出 账户 中 扣 款 并 加 到 转 入 账户 中 
transferTransactionManager.transfer (in fromAccount#, 
in toAccount#, in amount, out transferResponse); 
一 如 果 通过 ， 那 么 转账 响应 是 
— {successful, amount, Current Balance of From Account}; 
一 否则 转账 响应 是 {unsuccessful}; 
reply (client, transferResponse); 
Confirm: 
一 确认 取款 交易 成 功 完成 
withdrawalTransactionManager.confirm (in accountNumber, in amount); 
Abort: 
一 终止 转账 交易 
withdrawalTransactionManager.abort (in accountNumber, in amount); 
end case; 
end loop; 
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Software Modeling & Design: UML, Use Cases, Patterns, & Software Architectures 


面 问 服 务 的 体系 结构 案例 研究 : 在 线 购物 系统 





“在 线 购物 系统 ”案例 研究 是 一 个 高 度 分 布 的 基于 万 维 网 的 系统 ， 它 提供 了 在 线 购买 各 种 
商品 (例如 书 、 衣 服 等 ) 的 服务 。 该 案例 中 的 解决 方案 使 用 了 一 个 包括 多 个 服务 的 面向 服务 
的 体系 结构 ; 而 协调 者 对 象 被 用 来 帮助 服务 的 整合 。 另 外 ， 该 案例 还 使 用 了 对 象 代理 者 来 进 
行 服务 注册 、 代 理 和 发 现 。 案 例 中 涉及 的 服务 包括 一 个 目录 服务 、 一 个 库存 服务 、 一 个 客户 
账户 服务 、 一 个 配送 订单 服务 、 一 个 电子 邮件 服务 和 一 个 信用 卡 授权 服务 。 

22.1 节 提 供 问 题 描述 。22.2 节 描 述 “ 在 线 购物 系统 ”的 用 例 模型 。22.3 节 描 述 静 态 模型 ， 
包括 了 刻画 系统 和 外 部 环境 之 间 的 边界 的 系统 上 下 文 模型 。 在 继续 描述 实体 类 的 静态 建 模 之 
前 ， 这 一 节 也 描述 了 代理 者 技术 在 这 个 系统 中 的 应 用 。22.4 节 描 述 如 何 将 系统 划分 为 对 象 。 
22.5 节 描 述 为 每 个 用 例 开发 通信 图 的 动态 建 模 。22.6 节 描 述 系 统 的 设计 模型 ， 它 被 设计 为 一 
个 基于 分 层 抽象 模式 的 由 服务 和 构件 组 成 的 分 层 体系 结构 。 


22.1 问题 描述 


在 基于 Web 的 “在 线 购物 系统 ”中 ， 客 户 可 以 向 供应 商 请 求购 买 一 件 或 者 多 件 商品 。 客 户 
提供 个 人 信息 ,例如 地 址 和 信用 卡 信息 。 这 些 信息 被 存储 在 客户 账户 中 。 如 果 信 用 卡 是 有 效 的 ， 
那么 系统 创建 一 个 配送 订单 并 且 发 送 给 供应 商 。 供 应 商检 查 可 用 的 库存 ， 确 认 订单 ， 并 且 输 入 
一 个 计划 好 的 配送 日 期 。 当 订单 完成 配送 后 ， 系 统 通知 客户 并 且 向 客户 的 信用 卡 账户 收费 。 


22.2 ABER 


图 22-1 描绘 了 基于 Web 的 “在 线 购物 系统 ”的 用 例 模型 。 有 两 个 参与 者 :“ 客 户 ” 
( Customer ) 和 “供应 商 ”( Supplier )。 客 户 浏览 目录 和 请 求购 买 商 品 ， 供 应 商 提供 目录 和 服 
务 客户 的 购买 请 求 。 有 三 个 用 例 是 由 客户 发 起 的 ， 它 们 是 :“ 浏 览 目录 ”( Browse Catalog ), 
客户 浏览 目录 并 挑选 商品 ;“ 下 单 请 求 ”( Make Order Request )， 客 户 发 出 一 个 购买 请 求 ;“ 查 
看 订单 ”( View Order )， 客 户 查看 订单 详细 信息 。 有 两 个 用 例 是 由 供应 商 发 起 的 ， 即 “处 理 
配送 订单 ”( Process Delivery Order )， 以 满足 客户 的 订单 服务 ;“ 确 认 配 送 和 给 客户 开 账 单 ” 
( Confirm Shipment and Bill Customer )， 以 完成 购买 过 程 。 











Supplier 














图 22-1 基于 Web 的 “在 线 购物 系统 ”: 用 例 
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在 “浏览 目录 ”用 例 中 ， 客 户 浏览 一 个 万 维 网 的 目录 ， 查 看 来 自 于 给 定 供应 商 目录 的 各 
种 各 样 的 目录 商品 ， 并 从 目录 中 选择 商品 。 在 “下 单 请 求 ” 用 例 中 ， 客 户 输入 个 人 详细 信息 。 
如 果 账 户 不 存在 ， 系 统 就 创建 一 个 客户 账户 。 客 户 的 信用 卡 被 检查 其 有 效 性 和 是 否 有 足够 的 
额度 来 支付 请 求 的 目录 商品 。 如 果 信 用 卡 检查 显示 信用 卡 是 有 效 的 并 且 有 足够 的 人 额度， 那么 
客户 的 购买 请 求 被 通过 ， 系 统 发 送 购 买 请 求 给 供应 商 。 在 “查看 订单 ”中 ， 客 户 请 求 查 看 配 
送 订单 的 详细 信息 。 

供应 商 发 起 的 用 例 是 “处 理 配 送 订单 ”和 “确认 配送 和 给 客户 开 账 单 ”"。 在 “处 理 配 送 订 
单 ” 用 例 中 ， 供 应 商 请 求 一 个 配送 订单 ， 确 认 库存 满足 订单 ， 并 且 展 示 订 单 。 

在 “确认 配送 和 给 客户 开 账 单 ” 用 例 中 ， 供 应 商 通过 手工 方式 准备 配送 并 且 确 认 配 送 
已 经 准备 好 。 然 后 系统 从 客户 账户 中 检索 客户 的 信用 卡 信息 并 且 给 客户 的 信用 卡 开 账 单 。 

除了 非常 简单 的 “查看 订单 ”用 例 ， 我 们 对 其 他 用 例 都 将 进行 详细 的 描述 。 每 个 用 例 都 
会 用 文本 和 活动 图 两 种 方式 来 描述 。 活 动 图 在 业务 流程 建 模 中 使 用 很 普遍 ， 并 且 可 以 被 集成 
到 面向 服务 的 应 用 的 分 析 和 设计 中 ， 用 于 建 模 用 例 中 的 活动 序列 。 具 体 而 言 ， 活 动 图 可 以 准 ”[425] 


确 地 描述 主要 的 和 可 替换 的 用 例 序列 ， 精 确 地 刻画 了 它们 
之 间 的 区 别 。 
Catalog Information 
Catalog Items 
Items 
from Catalog 











2221 “浏览 目录 ”用 例 描述 


用 例 名 称 : 浏览 目录 
概述 : 客户 浏览 万 维 网 目录 ， 从 供应 商 的 目录 中 
查看 各 种 各 样 的 商品 项 ， 并 且 从 目录 中 选择 商品 。 
参与 者 : 客户 
前 置 条 件 :客户 的 浏览 器 链接 到 供应 商 的 目录 网 站 。 
主 序列 : 
1. 客户 请 求 浏览 目录 。 


2. 系统 向 客户 显示 目录 信息 。 
3. 客户 从 目录 中 选择 商品 。 
4. 系统 显示 商品 列表 ,包含 商品 描述 、 价 格 
以 及 总 价 。 
可 替换 序列 : FRI: 客户 没有 选择 商品 并 且 退 出 。 
后 置 条 件 : 系统 显示 了 所 选择 的 商品 列表 。 





图 22-2 中 的 活动 图 描述 了 “浏览 目录 ”用 例 中 的 
用 例 活动 序列 ， 对 应 于 前 面 所 描述 的 用 例 中 的 主 序列 。 
其 中 的 活动 包括 :“ 请 求 目 录 信 息 ”(Request Catalog 
Information )、“ 请 求 目 录 商 品 项 ”( Request Catalog Items )、 
“显示 目录 商品 ”( Display Catalog Items )、“ 从 目录 中 请 求 


from Catalog 

Total Price 
商品 ”( Request Items from Catalog )、“ 从 目录 中 选择 商品 ” 
( Select Items from Catalog ) “显示 商品 和 总 价 ”( Display 


Items and Total Price )。 图 22-2 “浏览 目录 ”用 例 的 活动 图 
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22.2.2 “下 单 请 求 ” 用 例 描述 


用 例 名 称 : 下 单 请 求 
概述 : 客户 输入 一 个 订单 请 求 来 购买 目录 商品 。 客 户 的 信用 卡 被 检查 其 有 效 性 和 是 
否 有 足够 的 额度 来 支付 请 求 的 目录 商品 。 
参与 者 : 客户 
前 置 条 件 : 客户 选择 了 一 个 或 者 多 个 目录 商品 。 
主 序列 : 
1. 客户 提供 订单 请 求 和 客户 账户 ID 来 支付 购买 。 
2. 系统 检索 客户 账户 信息 ， 包 括 客 户 的 信用 卡 详 细 信 息 。 
з. 系统 根据 购买 总 额 检查 客户 信用 卡 ， 如 果 通 过 ,创建 一 个 信用 卡 购买 授权 号 码 。 
4. 系统 创建 一 个 配送 订单 ， 包 括 订单 细节 、 客 户 ID 和 信用 卡 授 权 号 码 。 
5. 系统 确认 批准 购买 ， 并 且 向 客户 显示 订单 信息 。 
可 替换 序列 : 
步骤 2: 如 果 客 户 没 有 账户 ， 系 统 提示 客户 提供 信息 来 创建 一 个 新 账户 。 客 户 可 输入 
账户 信息 或 者 取消 订单 。 
步骤 3: 如 果 客 户 的 信用 卡 授 权 被 拒绝 (例如 ， 无 效 的 信用 卡 或 者 客户 的 信用 卡 账户 
资金 不 足 )， 系 统 提示 客户 输入 一 个 不 同 的 信用 卡号 码 。 客 户 可 输入 一 个 不 同 的 信用 卡号 
426 码 或 者 取消 订单 。 
| 后 置 条 件 : 系统 为 客户 创建 了 一 个 配送 订单 。 





“下 单 请 求 ”的 活动 图 ( 图 22-3 ) 描述 了 这 个 用 例 的 主 序列 对 应 的 活动 ， 即 “接收 订单 
请 求 ”( Receive Order Request), “获取 账户 信息 ”( Get Account Information )、“ 授 权 信 用 卡 ” 
( Authorize Credit Сага )、“ 创 建新 的 配送 订单 ”( Create New Delivery Order ) “电子 邮件 发 送 
和 显示 订单 确认 ”( Email and Display Order Confirmation )。 此 外 ， 该 活动 图 还 描述 了 两 个 可 
替换 序列 ， 即 账户 不 存在 时 “创建 新 账户 ”( Create New Account) 和 拒绝 信用 卡 授权 时 “ 显 
示 非 法 的 信用 卡 信息 ”( Display Invalid Credit Card )。 


22.2.3 “处 理 配送 订单 ”用 例 描述 


用 例 名 称 : 处 理 配 送 订 单 

概述 : 供应 商 请 求 一 个 配送 订单 ;系统 确定 库存 对 于 满足 订单 是 可 用 的 ， 并 且 显示 订单 。 
参与 者 : 供应 商 

前 置 条 件 : 供应 商 需要 处 理 一 个 配送 订单 并 且 一 个 配送 订单 存在 。 


主 序列 : 
1. 供应 商 请 求 下 一 个 配送 订单 。 
2. 系统 检索 并 且 显示 配送 订单 。 
3. 供应 商 为 配送 订单 请 求 商品 库存 检查 。 
4. 系统 确定 库存 中 的 商品 对 于 满足 订单 是 可 用 的 ， 并 且 保 留 这 些 商 品 。 
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5. 系统 给 供应 商 显 示 库 存 信 息 ， 并 且 确 认 商 品 被 保留 。 
可 替换 序列 : 步骤 4: 如 果 商 品 库存 不 足 ， 系 统 显示 警告 信息 。 


后 置 条 件 : 系统 为 配送 订单 保留 了 库存 商品 。 





“处 理 配 送 订单 ”的 活动 图 (图 22-4) 描述 了 这 个 用 例 的 主 序列 对 应 的 活动 ， 即 “ 接 
收 配送 订单 请 求 ”( Receive Delivery Order Request )、“ 检 索 和 显示 配送 订单 ”( Retrieve and 
Display Delivery Order )、“ 检 查 订单 商品 的 库存 ”( Check Inventory for Order Items )、“ 保 留 订 
单 商 品 ”( Reserve Order Items )、“ 显 示 库 存 信息 ”( Display Inventory Information )。 此 外 ， 该 


活动 图 还 描述 了 该 用 例 的 可 替换 序列 ， 即 库存 商品 不 足 时 “显示 库存 不 足 的 商品 ”( Display 
Items Out of Stock )。 





Receive 
Order Request 


[account does not =< 









Receive 
Delivery Order 
Request 


Retrieve and Display 
Delivery Order 
Check Inventory 
for Order Items 


[items not available] 








Ras exists] 


Get 
Account Information 








[invalid] 


[items available] 


Create Reserve 
New Delivery Order Order Items 
Email and Display Display 
Order Confirmation Inventory Information 
428 
a 


Е 22-3 “下 单 请 求 ” 用 例 的 活动 图 图 22-4 用例“ 处理 配 送 订单 ” 的 活动 图 1429 


п 


Displa 
Invalid Credit Card 





ispla 
Items Out of Stock 


kei 
; < 
о 
© 
< 






22.24 “确认 配送 和 给 客户 开 账 单 ” 用 例 描 述 


用 例 名 称 : 确认 配送 和 给 客户 开 账单 


概述 : 供应 商 手 工地 准备 配送 并 且 确 认 配 送 订单 已 经 准备 好 。 系 统 通知 客户 订单 正 





330 FORD ARARE 


在 配送 。 系 统 通 过 客户 的 信用 卡 收取 购买 商品 的 款项 并 且 更 新 相关 库存 商品 的 库存 。 
参与 者 : 供应 商 
前 置 条 件 : 库存 商品 已 经 为 客户 的 配送 订单 进行 了 预 留 。 
主 序列 : 
1. 供应 商 手 工地 准备 配送 并 且 确 认 配 送 订单 已 经 准备 好 配送 。 
.系统 检索 客户 的 账户 信息 ， 包 括 发 货 单 和 客户 的 信用 卡 细节 。 
. 系统 更 新 库存 ， 确 认购 买 。 


. 系统 用 信用 卡 收费 确认 号 码 更 新 配送 订单 信息 。 

. 系统 给 客户 发 送 确认 邮件 。 

. 系统 向 供应 商 显 示 确 认 信 息 来 完成 配送 订单 的 配送 。 
后 置 条 件 : 系统 提交 了 库存 ， 向 客户 收费 ， 并 且 发 送 了 确认 信息 。 


2 
3 
4. 系统 通过 客户 信用 卡 收取 购买 商品 的 款项 并 且 创 建 一 个 信用 卡 收费 确认 号 码 。 
5 
6 
7 





“确认 配送 和 给 客户 开 账 单 ” 的 活动 图 (图 22-5 ) 描述 了 这 个 用 例 的 主 序列 对 应 的 活 
动 ， 包 括 “ 收 到 配送 订单 就 绪 的 信息 ”( Receive Delivery Order is Ready ) “检索 客户 信息 ” 
( Retrieve Customer Information ) “更 新 库存 ”( Update Inventory )、“ 向 信用 卡 收费 ”( Charge 
Credit Card )、“ 更 新 配送 订单 ”( Update Delivery Order )、“ 向 客户 发 送 邮 件 和 显示 确认 信息 ” 
( Email and Display Confirmation to Customer )。 









Receive 
Delivery Order 
is Ready 


Retrieve 
Customer Information 
Update 
Inventory 
Charge 
Credit Card 
Update Delivery 
Order 


Email and Display 
Confirmation to 
Customer 

















Receive 
Order Status 
Request 


Order Information 


Display 
Order Information 


22-5 “确认 配送 和 给 客户 开 账 单 ” 用 例 的 活动 图 图 22-6 “查看 订单 ”用 例 的 活动 图 
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22.25 “查看 订单 ”用 例 的 活动 图 


在 这 个 简单 的 用 例 中 ， 客 户 请 求 查看 一 个 订单 。 图 22-6 描绘 了 “查看 订单 ”用 例 的 活动 
图 ， 其 中 的 活动 包括 “ 收 到 订单 状态 请 求 ”( Receive Order Status Request), “检索 订单 信息 ” 
( Retrieve Order Information ) “显示 订单 确认 信息 ”( Display Order Confirmation )。 


22.3 HSER 


本 节 描 述 静 态 模 型 ， 由 系统 上 下 文 模型 和 实体 类 模型 组 成 。 本 节 还 讨论 了 在 线 购物 系统 
的 面向 服务 的 体系 结构 中 代理 者 技术 的 使 用 。 


22.3.1 软件 系统 上 下 文 建 模 


软件 系统 的 上 下 文 模型 描述 了 两 个 作为 参与 者 的 外 部 用 户 类 ， 即 “客户 ”( Customer ) 类 
和 “供应 商 ”( Supplier ) 类 。 由 于 外 部 类 对 应 于 用 例 图 中 的 参与 者 ， 因 此 上 下 文 类 图 ( 
22-7) 与 用 例 图 非常 相似 。 


«software system» 5 
Interacts with | Online 44 Interacts with 
Shopping 
System 
Customer 





22-7 “在 线 购 物 系统 ”的 软件 系统 上 下 文 类 图 


22.3.2 ”问题 域 的 静态 实体 类 建 模 


问题 域 的 静态 模型 可 以 通过 类 图 来 描述 ( 图 22-8 )。 由 于 这 是 一 个 数据 密集 型 应 用 ， 因 
此 重点 是 在 实体 类 上 。 静 态 实体 类 模型 显示 了 实体 类 和 这 些 类 之 间 的 关系 。 这 些 类 包括 : Ж 
户 类 ， 包 括 “客户 ”( Customer ) 和 “客户 账户 ”( Customer Account); 供应 商 类 ， 包 括 “ 供 
MIRT” (Supplier), “EFF” (Inventory ) 和 “目录 ”( Catalog ); 处 理 客户 订单 的 类 ， 例如“ 配 
送 订单 ”( Delivery Order )， 它 是 一 个 “商品 项 ”( Item ) 的 聚合 。 图 22-9 显示 了 这 些 类 的 属 
性 。 这 个 例子 在 第 7 章 中 有 更 详细 的 描述 。 


«entity» 
Customer 









Provides 


Я 22-8 “在 线 购物 系统 ”实体 类 的 概念 静态 模型 
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«entity» «entity» 

DeliveryOrder Customer 
orderld : Integer 
orderStatus : OrderstatusType 
accountld : Integer 
amountDue: Real 
authorizationId: Integer 
supplierld : Integer 
creationDate ; Date 
plannedShipDate : Date 
actualShipDate : Date 
paymentDate: Date 


«entity» 
Inventory 
кеті : Integer 
itemDescription : String 
quantity : Integer 
price : Real 
reorderTime : Date 


«entity» 
Кет 


itemid ; Integer 
unitCost ; Real 
quantity : Integer 





customerld ; Integer 
customerName : String 
address ; String 
telephoneNumber : String 
faxNumber ; String 
emailld : Ета Type 


«entity» 
Supplier 


supplierld : Integer 
supplierName: String 
address : String 
telephoneNumber : String 
faxNumber : String 

email : EmailType 


«entity» 
CustomerAccount 


accountld : Integer 
саг ЛЗ : String 
cardType : String 
expirationDate: Date 


«entity» 

Catalog 
itemld ; Integer 
itemDescription : String 
unitCost : Real 
supplierld ; Integer 
itemDetails : linkType 








图 22-9 “在 线 购 物 系 统 ”的 实体 类 


224 对象 和 类 组 织 


在 上 一 节 中 确定 的 实体 类 可 以 通过 服务 类 的 形式 整合 到 面向 服务 的 体系 结构 中 。“ 目 
录 服 务 ”( Catalog Service ) “客户 账户 服务 ”(Customer Account Service ) “配送 订单 服 
务 ”( Delivery Order Service ) 和 “库存 服务 ”( Inventory Service ) 是 服务 类 ， 它 们 都 提供 了 
对 实体 类 的 访问 (图 22-10 )。“ 目 录 服 务 ” 使 用 了 “目录 ”(Catalog ) 实体 类 和 “供应 商 ” 
(Supplier) 实体 类 。“ 客 户 账户 服务 ”使 用 了 “客户 账户 ”实体 类 和 “客户 ”( Customer ) 实 
体 类 。“ 配 送 订单 服务 ”使 用 了 “配送 订单 ”( Delivery Order) 实体 类 和 “商品 ”(Item ) 实体 
类 。“ 库 存 服 务 ” 使 用 了 “库存 ”( Inventory ) 实体 类 。 





«service» 
DeliveryOrderService 


«entity» «entity» 
DeliveryOrder Item 


«service» 
CatalogService 


«entity» «entity» 
Catalog Supplier 



















«service» 
InventoryService 


«entity» 
Inventory 
«service» 


CustomerAccountService 


«entity» «entity» 
Customer CustomerAccount 








图 22-10 “在 线 购 物 系 统 ”的 服务 类 和 实体 类 
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还 有 一 个 服务 类 是 “信用 卡 服务 ”( Credit Card Service), EAHA KMRL A 
付费 。 通 过 这 种 方法 ， 信用卡 付 费 被 整合 到 客户 购买 和 供应 商 配 送 中 。 另 一 个 服务 类 
是 “电子 邮件 服务 ”( Email Service )， 它 使 得 “在 线 购物 系统 ”能 够 发 送 电 子 邮 件 给 
客户 。 

用 户 交互 类 需要 和 外 部 的 用 户 交 互 ， 具 体 而 言 是 “客户 交互 ”( Customer Interaction ) 
和 “供应 商 交 互 ”( Supplier Interaction) 类 ， 它 们 对 应 于 用 例 中 的 参与 者 。 此 外 ， 为 了 协调 
和 序列 化 客户 和 供应 商 对 在 线 购物 服务 的 访问 ， 要 提供 两 个 协调 者 对 象 ， 即 “客户 协调 者 ” 
(Customer Coordinator ) 和 “供应 商 协 调 者 ”( Supplier Coordinator )。 第 三 个 自治 协调 者 是 
“账单 协调 者 ”( Billing Coordinator )， 它 需要 给 客户 开 账单 -“ 在 线 购 物 系统 ”中 的 类 组 织 如 
图 22-11 所 示 。 








OnlineShoppingSystem 
«user interaction» «user interaction» 
Customer Supplier 
Interaction Interaction 
«coordinator «coordinatom «coordinator 
Customer Supplier Billing 
Coordinator Coordinator Coordinator 















«service» «service» «service» «service» «service» «service» 
Email CreditCard CustomerAccount Catalog DeliveryOrder Inventory 
Service Service Service Service Service Service 


图 22-11 “在 线 购物 系统 ”的 类 组 织 








225 ”动态 建 模 


对 于 每 个 用 例 我 们 需要 开发 一 个 通信 图 ， 用 于 描述 参与 该 用 例 的 对 象 以 及 这 些 对 象 之 间 
消息 传递 的 顺序 。 


22.5.1 “浏览 目录 ”用 例 的 动态 建 模 


在 “浏览 目录 ”( Browse Catalog) 用 例 的 通信 图 中 ( 22-12), “Жл Жн” Б 
“客户 协调 者 ”交互 ,，“ 客 户 协调 者 ”接着 又 与 “目录 服务 ”进行 通信 。 消 息 描 述 如 下 
所 示 : 


B1: 客户 通过 “客户 交互 ”发 出 一 个 目录 请 求 。 
B2 :“ 客 户 协 调 者 ”被 实例 化 来 帮助 客户 。 在 客户 请 求 的 基础 上 ,“ 客 户 协调 者 ”为 
客户 选择 一 个 目录 来 浏览 。 
:“ 客 户 协调 者 ”向 “目录 服务 ”请 求 信息 。 


:“ 目 录 服 务 ” 发 送 目 录 信 息 给 “客户 协调 者 ”。 
:“ 客 户 协调 者 ”把 信息 转发 给 “客户 交互 ”。 

:“ 客 户 交 互 ” 向 客户 显示 目录 信息 。 

: 客户 通过 “客户 交互 ”选择 一 个 目录 。 
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B8:“ 客 户 交互 ”传递 请 求 给 “客户 协调 者 ”。 
B9:“ 客 户 协调 者 ”向 “目录 服务 ”请 求 目 录 选 择 。 


0:“ 目 录 服 务 ”确认 目录 商品 的 可 用 性 并 且 发 送 商 品 价格 给 “客户 协调 者 ”。 
:“ 客 户 协调 者 ”转送 信息 给 “客户 交互 ”。 
2:“ 客 户 交 互 ”向 客户 显示 目录 信息 ， 包 括 商品 价格 和 总 价 。 





B2: Catalog Request 


ВІ,В7: Customer Input В8: Catalog Selection 
«user interaction» «coordinator 
: CustomerInteraction р нЕ aCustomerCoordinator 


BS: Catalog Info 
6. : Cata ри! 
aCustomer ок а B11: Selection Confirmation 











B3: Catalog Request B4: Catalog Info 
B9: Catalog Selection B10: Selection Confirmation 





«service» 


: CatalogService 


E 22-12 “浏览 目录 ”用 例 的 通信 图 


22.5.2 “下 单 请 求 ” 用 例 的 动态 建 模 


在 “下 单 请 求 ” 用 例 的 通信 图 中 ( 图 22-13 )， 一 个 客户 提供 账户 信息 ， 该 信息 被 用 于 访 
问 “客户 账户 服务 " 。 信 用 卡 信息 通过 “客户 协调 者 ”发 送 给 “信用 卡 服 务 ” 来 获得 授权 。 然 
后 “客户 协调 者 ”发 送 一 个 新 的 订单 请 求 给 “配送 订单 服务 "， 并 且 发 送 一 封 确认 邮件 给 “ 电 
子 邮件 服务 "。 消 息 描述 如 下 所 示 : 


M1; 客户 向 “客户 交互 ”提出 订单 请 求 。 

M2:“ 客 户 交互 ”将 订单 请 求 发 送 给 “客户 协调 者 ”。 

M3，M4 :“ 客 户 协调 者 ”发 送 账户 请 求 给 “客户 账户 服务 ”， 并 且 接 收 账户 信息 ， 包 
括 客户 的 信息 卡 详细 信息 。 

M5 :“ 客 户 协调 者 ”向 “信用 卡 服务 ”发 送 客户 的 信用 卡 信息 和 付款 授权 请 求 ( 这 相 
当 于 一 个 “准备 提交 ”( Prepare to Commit) 的 消息 )。 


M6:“ 信 用 卡 服 务 ” 向 “客户 协调 者 ”发 送 一 个 信用 卡 批 准 ( 这 相当 于 “准备 好 提交 ” 
(Ready to Commit ) 的 消息 )。 

M7，M8:“ 客 户 协 调 者 ”发 送 订 单 请 求 给 “配送 订单 服务 ”。 

M9，M9a :“ 客 户 协 调 者 ”发 送 订单 确认 给 “客户 交互 "， 并 且 通 过 “电子 邮件 服务 ” 
向 客户 发 送 一 封 订单 确认 的 邮件 。 

M10:“ 客 户 交互 ”向 客户 输出 订单 确认 。 





这 个 用 例 的 可 替换 场景 是 : 客户 没有 账户 ， 在 这 种 情况 下 需要 创建 一 个 新 的 账户 ; 或 者 
信用 卡 授权 被 拒绝 ， 在 这 种 情况 下 客户 有 选择 其 他 卡 的 选项 。 这 些 可 替换 的 场景 在 第 9 章 中 
有 所 描述 。 
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М1: Order Request 
一 > 


= 
M10: Customer Output 


aCustomer 


«user interaction» 
: Customer 
Interaction 








М2: Order Request у л М9: Order Confirmation 










М5: Authorize Credit Card Request M3: Account Request 


<— 
=> 
M6: Credit Card Approved 
















«service» 
: CreditCard 
Service 






«service» 
: CustomerAccountService 


=== 







«coordinator» 
aCustomerCoordinator 













=== 
М4: Account Info 












М9а: Send Order 
Confirmation Email 


z 


«service» 
: EmailService 


«service» 
: DeliveryOrderService 


Р 22-13 “下 单 请 求 ” 用 例 的 通信 图 





22.5.3 “处 理 配送 订单 ”用 例 的 动态 建 模 


在 “处 理 配送 订单 ”用 例 的 通信 图 中 ( 图 22-14 ),“ 供 应 商 协 调 者 ”向 “配送 订单 服务 ” 
请 求 一 个 新 的 配送 订单 ， 然 后 “配送 订单 服务 ”选择 一 个 配送 订单 。“ 供 应 商 协调 者 ”请 求 
“库存 服务 ”来 检查 库存 ， 并 且 通 过 用 户 交 互 对象 发 送 订 单 和 库存 信息 给 供应 商 。 消 息 描述 如 
下 所 示 : 


: 供应 商 请 求 一 个 新 的 配送 订单 。 
:“ 供 应 商 交 互 ” 向 “供应 商 协调 者 ”发 送 供 应 商 的 请 求 。 
:“ 供 应 商 协 调 者 ”请 求 “ 配 送 订单 服务 ”选择 一 个 配送 订单 。 
:“ 配 送 订单 服务 ”发 送 配 送 订单 给 “供应 商 协调 者 ”。 
:“ 供 应 商 协 调 者 ”请 求 检查 商品 库存 。 
:“ 库 存 服务 ”返回 商品 信息 。 
“供应 商 协调 者 ”发 送 订单 信息 给 “供应 商 交 互 ”。 
:“ 供 应 商 交 互 ” 向 供应 商 显示 配送 订单 的 信息 。 
: 供应 商 请 求 系统 在 库存 中 保留 商品 。 
D10:“ 供 应 商 交 互 ”发 送 供应 商 的 请 求 给 “供应 商 协 调 者 ”来 保留 库存 。 
D11:“ 供 应 商 协调 者 ”请 求 “库存 服务 ”来 保留 库存 中 的 商品 (这 相当 于 “准备 提交 ” 
的 消息 )。 
D12 :“ 库 存 服务 ”向 “供应 商 协调 者 ”确认 商品 的 保留 (这 相当 于 “准备 好 提交 ” 
的 消息 )。 
D13:“ 供 应 商 协调 者 ”发 送 库 存 状态 给 “供应 商 交互 ”。 
D14:“ 供 应 商 交 互 ”向 供应 商 显示 库存 信息 。 





这 个 用 例 的 一 个 可 替换 场景 (没有 显示 在 图 中 ) Æ: 商品 库存 不 够 ， 在 这 种 情况 下 “ 库 
存 服务 ”返回 一 个 “库存 不 够 ”( Out of stock) 的 消息 给 供应 商 。 
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«service» 
: Inventory 
Service 


DS: Check paar | D6: Item Info 
D11: Reserve Items D12: Items Reserved 


D2: Order Request, 


D1, D9: Supplier Input D10: Reserve Inventory 
=% 

















—= «user interaction» «coordinatom 
= = 
D8: Order Output, D7: Order Info, 
D14: Inventory Output D13: Inventory Status 


aSupplier 


D3: Select Order 
D13a: Prepare To у 


1 D4: Selected Order 
Commit 





«service» 
: DeliveryOrder 
Service 


22-14 “处 理 配 送 订 单 ” 用 例 的 通信 图 


22.5.4 “确认 配送 和 给 客户 开 账 单 ” 用 例 的 动态 建 模 


在 用 例 “ 确 认 配 送 和 给 客户 开 账 单 ” 的 通信 图 中 ( 图 22-15 )， 供 应 商 手 工 准备 配送 。 供 
应 商 发 送 “ 准 备 好 配送 ”( Ready for Shipment) 的 消息 给 “供应 商 协调 者 ”,“ 供 应 商 协 调 者 ” 
请 求 “ 库 存 服务 ”以 提交 库存 ， 并 发 送 “ 准 备 好 配送 ”的 消息 给 “账单 协调 者 "。“ 账 单 协调 
者 ”向 “配送 订单 服务 ”索取 发 货 单 ， 向 “客户 账户 服务 ”索取 账户 信息 ， 并 且 通 过 “信用 
卡 服务 ”向 客户 收费 。 对 人 信用卡、 配送 订单 和 库存 的 更 新 通过 使 用 两 阶段 提交 协议 ( 见 第 16 
章 ) 来 协调 。 消 息 描述 如 下 所 示 : 


S1: 供应 商 输入 配送 信息 。 

S2:“ 供 应 商 交互 ”发 送 “ 准 备 好 配送 ”的 请 求 给 “供应 商 协调 者 ”。 

S3 :“ 供 应 商 协调 者 ”发 送 “ 订 单 准备 好 配送 ”( Order Ready for Shipment) 的 消息 
给 “账单 协调 者 ”。 

S4:“ 账 单 协调 者 ”发 送 “ 准 备 提交 ”订单 给 “配送 订单 服务 ”。 

S5 :“ 配 送 订单 服务 ”回复 “准备 好 提交 ”的 消息 和 发 货 单 ， 包 括 订单 号 、 账 户 号 和 
总 价 。 


S6，S7 :“ 账 单 协调 者 ”发 送 账 户 请 求 给 “客户 账户 服务 ”",， “客户 账户 服务 ”返回 


账户 信息 。 

S8，S8a，S8b，S8c :“ 账 单 协调 者 ”发 送 “ 提 交 收 费 ”( Commit Charge) 的 消息 
给 “信用 卡 服 务 ”"， 发 送 “ 提 交 支 付 ”( commit Payment) 的 消息 给 “配送 订单 服务 "， 通 
过 “电子 邮件 服务 ”发 送 确认 邮件 给 客户 ， 发 送 “ 账 户 已 开 账 单 ”( Account Billed) 的 消 
息 给 “客户 协调 者 ”。 

S9，S10 :“ 供 应 商 协调 者 ”发 送 “ 提 交 库 存 ” 的 消息 给 “库存 服务 ",“ 上 库存 服务 ” 
返回 提交 已 完成 。 
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S11，S12 :“ 供 应 商 协调 者 ”发 送 确认 响应 给 “供应 商 交互 ",“ 供 应 商 交 互 ”接着 


发 送 配送 确认 消息 给 供应 商 。 
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图 22-15 “确认 配送 和 给 客户 开 账 单 ” 用 例 的 通信 图 
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2255 “查看 订单 ”用 例 的 动态 建 模 


在 “查看 订单 ”用 例 的 通信 图 中 (图 22-16 ),“ 客 户 交 互 ” 与 “客户 协调 者 ”交互 ,，“ 客 
户 协调 者 ”接着 又 与 “配送 订单 服务 ”通信 。 消 息 描述 如 下 所 示 : 


V2: 客户 通过 “客户 交互 ”发 出 一 个 订单 发 货 单 的 请 求 。 
:“ 客 户 协 调 者 ”向 “配送 订单 服务 ”发 出 一 个 订单 请 求 。 


:“ 配 送 订单 服务 ”发 送 订单 发 货 单 信息 给 “客户 协调 者 ”。 
:“ 客 户 协调 者 ”转送 信息 给 “客户 交互 ”。 
:“ 客 户 交 互 ” 向 客户 显示 订单 信息 。 





V4: Order Invoice 






=> 
V2: Order Request V3: Order Request 


图 22-16 “查看 订单 ”用 例 的 通信 图 


aCustomer 
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22.6 面向 服务 体系 结构 的 代理 者 和 包装 器 技术 支持 


“在 线 购物 系统 ”中 使 用 了 多 个 遗留 数据 库 。 静 态 模 型 中 的 许多 实体 类 代表 了 存储 在 遗留 
数据 库 中 的 持久 化 数据 ， 每 个 遗留 数据 库 都 是 一 个 驻 留 在 大 型 机 上 的 单机 数据 库 ， 这 些 数 据 
库 需 要 通过 代理 者 和 包装 器 技术 整合 到 应 用 中 。 第 15 章 介绍 了 关于 数据 库 包 装 器 类 的 信息 ， 
而 第 16 章 则 介绍 了 代理 者 模式 的 信息 。 

尽管 存在 着 不 同 的 遗留 数据 库 ， 但 对 象 代理 者 和 包装 器 技术 提供 了 一 种 系统 的 方法 来 把 
异 构 的 遗留 数据 库 整 合 为 一 个 面向 服务 的 体系 结构 。 在 供应 商 组 织 内 的 遗留 数据 库 包括 目录 
数据 库 、 库 存 数据 库 、 客 户 账户 数据 库 和 配送 订单 数据 库 。 

数据 库 包 装 器 类 被 设计 用 来 为 遗留 数据 库 提供 一 个 面向 对 象 的 接口 ， 这 个 接口 隐藏 了 如 
何 读 取 和 更 新 个 体 数据 库 的 细节 。 为 了 把 这 些 数据 库 整 合 到 在 线 购物 应 用 中 ， 服 务 类 被 设计 
为 通过 数据 库 包 装 器 类 来 访问 遗留 数据 库 。 
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本 节 介 绍 了 在 设计 、 并 发 软件 设计 、 服 务 和 构件 接口 设计 以 及 面向 服务 的 体系 结构 设计 
(完全 整合 了 服务 和 构件 ) 中 使 用 的 体系 结构 的 组 织 和 通信 和 模式。 


22.7.1 面向 服务 的 体系 结构 概述 


在 面向 服务 的 体系 结构 中 ， 服 务 通过 代理 者 注册 它们 的 服务 名 字 和 位 置 。 这 样 ， 客 户 端 
就 可 以 使 用 “服务 发 现 ” 模 式 ( 也 被 认为 是 黄页 ) 来 发 现 新 的 服务 ， 从 而 向 代理 者 查询 给 定 
类 型 的 服务 。 客 户 端 可 以 选择 一 个 服务 ， 并 且 发 送 一 个 白 页 请 求 给 代理 者 。 

基于 分 层 抽象 体系 结构 模式 ,“ 在 线 购物 系统 ”可 以 被 设计 为 一 个 分 层 的 体系 结构 。 软 件 
体系 结构 由 三 层 组 成 : 一 个 服务 层 、 一 个 协调 者 层 和 一 个 用 户 交互 层 。 此 外 ， 因 为 这 个 系统 
需要 是 高 度 灵活 和 分 布 式 的 ， 所 以 决定 设计 为 一 个 面向 服务 的 体系 结构 。 在 这 种 体系 结构 中 ， 
分 布 式 构件 能 够 发 现 服务 并 且 与 它们 通信 。 

每 个 构件 通过 构件 构造 型 ( 它 是 什么 类 型 的 构件 ， 按 照 构件 组 织 准 则 中 所 定义 的 构件 类 
型 ) 来 描述 。 构 件 和 服务 接口 设计 是 通过 分 析 每 个 用 例 的 通信 图 来 确定 的 。 


22.7.2 分 层 软 件 体系 结构 


构件 被 组 织 到 分 层 的 体系 结构 中 ,使 得 每 个 构件 处 于 只 依赖 于 所 处 位 置 的 下 层 而 不 是 上 
层 的 构件 的 层次 。 这 种 分 层 的 体系 结构 是 基于 分 层 抽象 体系 结构 模式 的 (第 12 章 )。 这 种 分 
层 的 体系 结构 便于 在 线 购物 软件 体系 结构 在 将 来 的 适应 性 变化 。 用 户 交 互 层 的 用 户 交互 构件 
只 与 协调 者 构件 通信 ， 而 协调 者 构件 与 服务 通信 。 通 过 应 用 构件 组 织 准则 ， 我 们 可 以 确定 以 
下 按 层次 组 织 的 构件 和 服务 ， 如 图 22-17 所 示 。 

层次 1: ARSE (Service Layer), HA 6 个 服务 ，4 个 是 应 用 的 一 部 分 ，2 个 是 外 部 服务 。 
应 用 服务 包括 “目录 服务 ”( Catalog Service ) “配送 订单 服务 ”( Delivery Order Service )、 
“库存 服务 ”( Inventory Service ) 和 “客户 账户 服务 ”( Customer Account Service )。 外 部 服 
务 包括 用 于 向 客户 收取 购买 费用 的 “信用 卡 服务 ”( Credit Card Service ) 以 及 给 客户 发 邮件 
消息 的 “电子 邮件 服务 ”( Email Service )。 其 中 ， 每 个 信用 卡 公 司 都 有 一 个 服务 ， 如 万 事 达 
( Mastercard ) 和 维 萨 (Visa )。 
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层次 2: 协调 层 (Coordination Layer )。 共 有 3 个 协调 者 构件 :“ 供 应 商 协调 者 ”( Supplier 
Coordinator ) “客户 协调 者 ”( Customer Coordinator ) 和 “账单 协调 者 ”( Billing Coordinator )。 

层次 3 : 用 户 层 (User Layer)。 共 有 2 个 用 户 交 互 构件 :“ 供 应 商 交 互 ”( Supplier 
Interaction ) 和 “客户 交互 ”( Customer Interaction )。 
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Н 22-17 “在 线 购物 系统 ”的 分 层 体系 结构 
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22.7.3 体系 结构 通信 模式 


为 了 处 理 软件 体系 结构 中 构件 之 间 的 多 种 通信 方式 ， 这 里 应 用 了 以 下 几 种 通信 模式 : 

• 带 回 复 的 同步 消息 通信 。 这 是 典型 的 面向 服务 的 体系 结构 的 通信 模式 ， 当 客户 端 需要 
服务 的 信息 并 且 在 接受 响应 之 前 不 能 继续 执行 的 时 候 使 用 这 个 模式 。 该 模式 被 用 于 用 
户 交 互 客户 端 和 协调 者 之 间 ， 也 被 用 于 协调 者 和 各 种 服务 之 间 。 

• 代理 者 句柄 。 每 个 服务 向 代理 者 注册 服务 信息 ， 包 括 服务 名 称 、 服 务 描 述 和 位 置 。 
“代理 者 句柄 ”模式 允许 客户 查询 代理 者 来 确定 它们 应 该 连接 的 服务 。 

© 服务 发 现 。“ 服 务 发 现 ”模式 被 服务 请 求 者 使 用 来 发 现 新 的 服务 。 它 们 能 够 用 于 发 现 
新 的 可 浏览 目录 。 

• 双向 异步 消息 通信 。 这 个 模式 被 用 于 “供应 商 协调 者 ”和 “账单 协调 者 ”之 间 的 双向 
异步 通信 。 

e 两 阶段 提交 。 这 个 模式 被 用 于 确保 对 库存 、 信 用 卡 和 配送 订单 的 更 新 是 原子 的 ， 即 所 
有 的 更 新 不 是 被 提交 就 是 被 中 止 。 


2274 并 发 软件 设计 


面向 服务 的 体系 结构 是 通过 集成 22.5 节 中 描述 的 基于 用 例 的 交互 图 然后 设计 消息 接口 的 
方式 来 设计 的 。“ 在 线 购物 系统 ”的 并 发 通信 图 ( 图 22-18) 中 描述 了 并 发 软件 的 设计 ， 其 中 
包括 并 发 构件 和 服务 。 它 表示 由 支持 用 例 的 个 体 通 信和 图 整合 而 成 的 通信 和 图。 此外， 它 也 描绘 
了 消息 交互 的 设计 。 
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为 了 保持 设计 的 简单 ,“ 带 回复 的 同步 消息 通信 ”模式 被 广泛 地 使 用 在 这 个 案例 研究 中 。 
然而 ， 如 第 12 章 中 所 述 ， 该 方法 的 劣势 是 当 客 户 在 等 待 服务 的 响应 时 要 挂 起 客户 端 。 一 个 
可 替换 的 避免 挂 起 客户 端的 设计 是 使 用 “ 带 回 调 的 异步 消息 通信 ”模式 ， 如 第 15 章 中 所 述 。 


“双向 异步 通信 ”模式 被 用 于 “供应 商 协调 者 ”和 “账单 协调 
者 ”之 间 的 双向 通信 。 


2275 ”服务 接口 设计 


服务 接口 按照 以 下 方式 设计 。 每 个 服务 有 一 个 供给 接 
口 ， 通 过 这 个 接口 访问 服务 的 操作 。 图 22-19 描述 了 服务 接 
口 和 端口 。 服 务 的 客户 端 同步 地 调用 由 接口 提供 的 相应 的 
操作 。 

服务 操作 是 通过 考虑 在 基于 用 例 的 交互 图 中 各 个 服务 是 
如 何 被 访问 来 设计 的 。 通 常 ， 每 个 服务 可 以 通过 不 同 的 方式 
来 访问 ， 对 应 于 对 不 同 服务 操作 的 请 求 。 交 互 图 描述 了 到 达 
一 个 服务 的 消息 ( 对 应 于 服务 操作 的 调用 以 及 可 能 的 服务 输 
KBR) 以 及 服务 响应 的 消息 ( 对 应 于 服务 返回 的 数据 )， 服 
务 响应 的 消息 不 是 同步 的 ( 作为 一 个 同步 消息 的 回复 ) 就 是 
异步 的 (在 一 个 单独 的 异步 消息 中 )。 

“目录 服务 ”具有 请 求 查 看 目录 以 及 选择 目录 商品 的 操 
作 ( 图 22-20 )。 这 些 操作 访问 “目录 信息 ”( Catalog Info ) 
和 “商品 信息 ”( Item Info) 实体 类 中 所 保存 的 数据 。 这 些 
访问 需求 是 从 “浏览 目录 ”通信 图 ( 见 图 22-7 ) MBAR 
型 ( 见 图 22-3 和 22-4 ) 中 确定 的 。 操 作 requestCatalog 返回 
给 定 类 型 的 目录 商品 ， 是 从 图 22-12 中 的 消息 B3 中 确定 的 。 
返回 的 目录 信息 是 由 图 22-9 和 图 22-20 中 的 “目录 ”实体 类 
的 属性 给 出 的 。 操 作 requestSelection 是 从 图 22-12 中 的 消息 
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图 22-19 ”服务 的 构件 端口 和 接口 


B9 中 确定 的 ， 它 返回 特定 商品 的 商品 信息 ( 从 消息 B10 中 
确定 )。 

“客户 账户 服务 ”( Customer Account Service ) 具有 创建 一 个 新 账户 、 更 新 账户 和 读 取 
一 个 账户 的 操作 ( 图 22-21 )。 这 些 操作 访问 “客户 账户 ”( Customer Account) 和 “客户 ” 
(Customer ) 实体 类 中 所 保存 的 数据 ， 是 从 “下 单 请 求 ”的 通信 图 ( 见 图 22-13) 中 确定 的 。 
“请 求 账 户 ”( requestAccount ) 操作 对 应 于 图 22-13 中 的 消息 M3 以 及 “确认 配送 和 给 客户 
开 账 单 ”的 通信 图 ( 见 图 22-15 ) 中 的 消息 S6.“ 创 建 账户 ”( createAccount ) 和 “更 新 账 
户 ”(updateAccount ) 操作 对 应 于 “发 出 订单 请 求 ”的 主 序列 的 可 替换 序列 ， 如 22.5.2 节 
所 述 。 

“确定 配送 和 给 客户 开 账 单 ”( 见 图 22-8 ) 也 涉及 “配送 订单 服务 ”( 提交 支付 )“ 信 用 
卡 服务 ”( 授权 付费 ) 以 及 “电子 邮件 服务 ”( 发 送 确认 邮件 )。 

“下 单 请 求 ”通信 图 也 涉及 这 三 个 服务 :“ 配 送 订单 服务 “信用 卡 服 务 ” 以 及 “电子 邮 
件 服务 ”。 
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图 22-20 “目录 服务 ”的 服务 接口 
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Я 22-21 “客户 账户 服务 ”的 服务 接口 


“配送 订单 服务 ”具有 几 个 操作 (图 22-22 )， 它 们 按照 以 下 方式 确定 。 这 些 操作 访 
问 “ 配 送 订 单 ”(Delivery Order) 和 “商品 项 ”( Item ) 实体 类 中 所 保存 的 数据 ,“ 发 货 单 ” 
(Invoice ) 实体 类 包含 了 从 “配送 订单 ”中 抽取 的 数据 。 存 储 配送 订单 的 消息 М7 ( 见 图 22-13 ) 
对 应 于 图 22-22 中 “配送 订单 服务 ”的 “保存 ”( store ) 操作 。“ 处 理 配 送 订 单 ” 通 信 图 (м, 
22-14 ) 中 选择 配送 订单 的 消息 D3 对 应 于 图 22-22 中 的 “选择 ”( select ) 操作 。 其 他 的 操 
作 是 从 “确认 配送 和 给 客户 开 账 单 ” 的 通信 图 ( 见 图 22-15 ) 中 确定 的 ， 特 别 是 “配送 订单 
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服务 ”的 “准备 提交 ”订单 的 消息 ( 消息 S4 ) 和 “提交 支付 ”的 消息 ( 消息 S8b )。“ 读 取 ” 
(read) 操作 是 从 “查看 订单 ”的 通信 图 ( 见 图 22-16) 中 的 消息 УЗ 确定 的 。“ 配 送 订单 服务 ” 
的 服务 接口 在 图 22-22 中 被 描绘 。 如 果 订 单 在 配送 之 前 被 取消 了 ,“ 终 止 ”( abort ) 操作 就 会 


被 调用 。 


«interface» А х 
IDeliveryOrderService IeliverOrderService 


store (in order, out orderld) 
select(in supplierld, out order) 

update(in orderld, in order, out orderStatus) 
orderShipped (in orderld, out orderStatus) 


confirmPayment (in orderld, in amount, out orderStatus) 


read (in orderld, out order) 


requestInvoice (in orderld, out invoice) 
prepareToCommitOrder (in orderld, out order) 


commit (in orderld) 
abort (in orderld) 


«entity» 
DeliveryOrder 


orderld : Integer 
orderStatus : OrderStatus 
accountld : Integer 
amountDue: Real 
authorizationId: Integer 
supplierld : Integer 
creationDate : Date 
plannedShipDate : Date 
actualShipDate : Date 
paymentDate: Date 


















图 22-22 


“库存 服务 ”需要 操作 来 检查 库存 ( 从 图 22-14 中 的 消息 D5 确认 )、 保 留 库 存 (从 
图 22-14 中 的 消息 D11 确认 ， 相 当 于 准备 提交 库存 )、 提 交 库 存 ( 图 22-15 中 的 消息 S9 ) 以 
及 更 新 库存 。 如 果 在 配送 之 前 订单 被 取消 并 且 库 存 被 释放 ,“ 终 止 ”(abort ) 操作 就 会 被 调用 。 
补充 库存 之 后 ， 就 需要 执行 “更 新 库存 ”(updateInventory ) 操作 。16.6 节 更 详细 地 描述 了 这 


个 例子 。 









update (in itemld, in amount) 


itemID : Integer 
itemDescription : String 


quantity : Integer 
quantityReserved: Integer 
price : Real 

reorderTime : Date 


图 22-23 





«interface» 
UInventoryService 


checkInventory (in itemld, out inventoryStatus) 





reservelnventory (in itemld, in amount) 
commitInventory (in itemld, in amount) 
abortinventory (in itemld, in amount) 


«entity» 
Inventory 









PDOService 


«service» 
DeliveryOrder 
Service 





Item OrderStatus 










itemld : Integer 
unitCost ; Real 
quantity : Integer 


NotYetShipped 
PreparedForShipment 
Shipped 













orderld : Integer 
ассошп а : Integer 
amountDue : Real 
actualShipDate : Date 
authorizationId : Integer 


“配送 订单 服务 ”的 服务 接口 















IInventoryService 


PInventoryService 


«service» 


Inventory 
Service 





«entity» 
InventoryStatus 


itemID : Integer 


currentAmount: [nteger 
quantityA fterShipped: Integer 
reorderTime : Date 





“库存 服务 ”的 服务 接口 
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图 22-24 描述 了 外 部 服务 “信用 卡 服务 ”和 “电子 邮件 服务 ”的 服务 接口 。 这 两 个 外 部 
服务 都 有 和 应 用 服务 一 样 的 服务 接口 。“ 信 用 卡 服务 ”支持 一 个 供给 接口 ， 它 有 两 个 操作 : 一 
个 是 授权 信用 卡 购买 (“下 单 请 求 ” 中 的 消息 M5 )， 另 一 个 是 信用 卡 支付 (“确认 配送 和 给 客 
户 开 账 单 ” 中 的 消息 S8a )。“ 电 子 邮件 服务 ”有 一 个 供给 接口 ， 它 有 一 个 操作 来 发 送 邮 件 消 
息 (“下 单 请 求 ”中 的 消息 Мда 以 及 “确认 配送 和 给 客户 开 账 单 ” 中 的 消息 S8c )。 


ICreditCardService 







PCreditCardService 


«interface» 
1CreditCardService 
ee ee eee N ЕН 


authorizeCharge (in стедисаг 4, in amount, out authorizationResponse) 
commitCharge (in creditcardld, in amount, out chargeResponse) 
abortCharge (in creditcardld, in amount, out chargeResponse) 








«service» 
CreditCard 
Service 






IEmailService 


PEmailService 


«interface» 
IEmailService «service» 
Email 
Service 


sendEmail (in emailld, in emailText) 





图 22-24 “信用 卡 服务 ”和 “电子 邮件 服务 ”的 服务 接口 


22.7.6 面向 服务 的 软件 体系 结构 设计 


本 节 介 绍 了 “在 线 购物 系统 ”的 面向 服务 的 体系 结构 设计 ， 如 图 22-25 中 的 复合 结构 图 
所 示 。 前 一 节 中 已 经 介绍 了 服务 接口 的 设计 ， 而 下 一 节 将 会 介绍 被 设计 为 构件 的 用 户 交 互 和 
协调 者 对 象 。 

每 个 服务 有 一 个 带 有 供给 接口 的 端口 ， 而 每 个 协调 者 构件 有 一 个 或 多 个 带 有 供给 接口 、 
请 求 接口 或 两 者 都 有 的 端口 。 在 三 层 体 系 结构 中 ， 每 个 客户 端 - 用 户 交互 构件 有 一 个 请 求 端 
口 ， 它 支持 一 个 请 求 接口 。 每 个 服务 有 一 个 供给 端口 ， 它 支持 一 个 供给 接口 。 协 调 者 有 带 有 
请 求 和 供给 接口 的 端口 ， 因 为 它们 作为 客户 端 和 服务 的 中 介 者 且 需 要 与 多 个 服务 通信 。 为 了 
表明 服务 是 想 要 被 发 现 的 ， 服 务 的 供给 接口 和 协调 者 的 请 求 端口 被 明确 地 描绘 出 来 。 因 此 ， 
服务 请 求 者 和 服务 提供 者 之 间 的 绑 定 是 动态 的 。 

对 于 客户 请 求 ,“ 客 户 交 互 ”是 一 个 客户 端 ， 因 此 只 有 一 个 请 求 端口 。“ 客 户 交 互 ” 既 有 
请 求 端口 又 有 供给 端口 。“ 客 户 交 互 ”仅仅 与 “客户 协调 者 ”通信 ， 而 “客户 协调 者 ”会 与 五 
个 服务 通信 ， 这 五 个 服务 中 有 两 个 外 部 服务 (“信用 卡 服 务 ” 和 “电子 邮件 服务 "”) 和 三 个 应 
用 服务 (“目录 服务 、 配 送 订单 服务 ”和 “客户 账户 服务 ”)。 

对 于 供应 商 请 求 ,“ 供 应 商 交互 ”有 一 个 请 求 端口 ， 而 “供应 商 协 调 者 ”构件 既 有 供给 
接口 又 有 请 求 接 口 。“ 供 应 商 交 互 ” 仅 仅 与 “供应 商 协 调 者 ”通信 ， 而 “供应 商 协调 者 ”会 与 
“配送 订单 服务 ”和 “库存 服务 ”通信 。“ 供 应 商 协 调 者 ”也 会 和 “账单 协调 者 ”通信 。“ 账 单 
协调 者 ”会 与 四 个 服务 通信 ， 这 四 个 服务 中 有 两 个 外 部 服务 (“信用 卡 服 务 ” 和 “电子 邮件 服 
务 ”) 和 两 个 应 用 服务 (“配送 订单 服务 ”和 “客户 账户 服务 ”)。 由 于 所 有 的 客户 支付 是 通过 
信用 卡 完成 的 ， 这 就 使 得 “信用 卡 服务 ”成 为 必要 的 服务 ， 它 会 有 许多 服务 实例 ， 每 个 信用 
卡 公司 都 有 一 个 。 每 个 服务 实例 可 以 按照 不 同 的 方式 加 以 设计 和 实现 ， 但 是 都 必须 符合 SOA 
的 信用 卡 接口 。 
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2277 ”构件 端口 和 接口 设计 


接 下 来 将 描述 用 户 交 互 和 协调 构件 的 端口 和 接口 。 用 户 交 互 构件 “客户 交互 ”( Customer 
Interaction) 有 一 个 请 求 端口 ， 它 由 一 个 请 求 接口 组 成 。 ”供应 商 交 互 ”( Supplier Interaction ) 
也 是 这 样 ， 如 图 22-25 和 图 22-26 所 示 。 


«user interaction 


«user interaction component» 


сотропепі» 
CustomerInteraction 


Supplier 
Interaction 





RCustomerCoordinator RSupplierCoordinator 


ICustomerCoordinator [SupplierCoordinator 


Я 22-26 “客户 交互 ”和 “供应 商 交 互 ”构件 端口 和 接口 


图 22-27 描述 了 “客户 协调 者 ”构件 端口 和 接口 ， 其 中 还 描述 了 构件 的 供给 接口 和 请 求 
接口 。“ 客 户 协调 者 ”有 5 个 请 求 端口 和 1 个 供给 端口 。 请 求 端口 支持 “目录 服务 ”( Catalog 
Service ) “客户 账户 服务 ”(Customer Account Service )、“ 配 送 订 单 服务 ”( Delivery Order 
Service )、“ 电 子 邮 件 服务 ”( Email Service) 以 及 “信用 卡 服务 ”( Credit Card Service) 的 请 
求 接口 ， 这 是 因为 在 与 服务 通信 时 “客户 协调 者 ”是 一 个 客户 端 。 每 个 “客户 协调 者 ”构件 
有 一 个 供给 端口 与 “客户 交互 ”通信 。 


ICustomerCoordinator 
















«interface» | 
ICustomerCoordinator PCustomerCoordinator 





«coordinator» 
«component» 


requestCatalog(in selectedCatalog, out cataloginfo) 
requestSelectionFromCatalog(in пета, out itemInfo) 
requestPurchase(in purchaselnfo, out orderInfo) 
requestAccount(in accountld, out accountlnfo) 


Customer 
Coordinator 








requestOrderStatus(in orderld, out orderInfo) REmail RCatalog IDeliveryOrderService 
Service Service 
RCreditCard RCustAccount 
Service Service 
ICreditCard [Email [Catalog ICustomerAccount 
Service Service Service Service 


图 22-27 “客户 协调 者 ”构件 端口 和 接口 


图 22-28 描述 了 “供应 商 交 互 ” 构 件 端口 和 接口 。“ 供 应 商 协调 者 ”通过 端口 
PSupplierCoordinator 接收 来 自 于 “供应 商 交 互 ”的 供应 商 请 求 ， 这 个 端口 支持 一 个 供给 接 
口 ISupplierCoordinator。“ 供 应 商 协调 者 ”是 “库存 服务 ”的 一 个 客户 端 ， 并 通过 请 求 接口 
IInventoryService 与 之 通信 。 它 像 “ 客 户 协调 者 ”一 样 是 “配送 订单 服务 ”的 客户 端 ， 并且 有 
相同 的 请 求 接口 [DeliveryOrderService。“ 供 应 商 协 调 者 ”也 与 “账单 协调 者 ”通信 ， 就 像 在 
图 22-15 中 所 描绘 的 ， 当 一 个 订单 准备 好 配送 和 开 账 单 时 发 送 给 它 一 个 消息 ( S3 )。 这 个 通信 
的 接口 是 IShipment。 

“账单 协调 者 ”( 见 图 22-29 ) 通过 请 求 端口 与 两 个 外 部 服务 (“信用 卡 服务 ”和 “电子 邮 
件 服务 ”) 以 及 两 个 应 用 服务 (“配送 订单 服务 ”和 “客户 账户 服务 ”) 通信 。 它 还 有 一 个 供给 
接口 IShipment。 
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ISupplierCoordinator 









PSupplierCoordinator 














«interface» 
[SupplierCoordinator «coordinator» 
«component» 
Supplier 
Coordinator 








confirmShipment (in огдета) [Shipment 
requestOrder (in supplierld, out orderld) 
checkInventory (in orderld, out inventorylnfo) 

reservelnventory (in orderld, out іпуепіогуіпѓо) 


RinventoryService 


IDeliveryOrderService ПпуетмогуЅегуісе 


图 22-28 “供应 商 协 调 者 ”构件 端口 和 接口 
| PInterCoordinator 
«interface» «соогдіпаіог» [ 0 IShipment 
[Shipment 《componenty 
Billing 
Coordinator 










ја де а ынан ви А ЕЈ 
orderReadyForShipment (in orderld, in 
orderStatus) 


REmail RCustAccount 
Service Service 


RCreditCard Ld 
Service 


RDOService 


IDeliveryOrderService 
ICreditCard IEmail ICustomerAccount 
Service Service Service 


图 22-29 “账单 协调 者 ”构件 端口 和 接口 


22.8 服务 复 用 


利用 面向 服务 的 体系 结构 开发 范例 ,一旦 完成 了 服务 的 设计 以 及 接口 规约 ， 服 务 的 接口 
信息 就 可 以 注册 到 一 个 服务 代理 者 。 服 务 可 以 被 组 合 为 新 的 应 用 。 这 个 案例 研究 介绍 了 一 个 
“在 线 购物 系统 ”"。 然 而 ， 其 他 电子 商务 系统 的 设计 可 以 复 用 这 个 “在 线 购物 系统 ”提供 的 服 
务 ， 例 如 “目录 服务 ”"、“ 配 送 订 单 服务 ”以 及 “库存 服务 ”。 

例如 ， 在 一 个 B2B (Business to Business， 商 业 对 商业 ) 系统 中 ， 商 业 客户 和 供应 商 之 间 
可 能 建立 了 契约 而 不 是 使 用 客户 账户 。 每 个 契约 可 能 存在 于 一 个 特定 的 商业 客户 和 一 个 特定 
的 供应 商 之 间 ， 可 能 会 持续 一 段 指 定 的 时 间 ， 并 可 能 有 一 个 指定 货币 的 最 大 金额 。 一 个 商业 
客户 将 从 目录 中 选择 商品 ， 指 定 应 该 被 使 用 的 契约 ， 然 后 发 送 一 个 配送 订单 。 一 旦 订单 完成 
了 配送 ， 向 供应 商 的 支付 将 会 通过 从 商业 客户 银行 到 供应 商 银行 的 电子 资金 转移 来 完成 。 

这 个 B2B 系统 将 需要 创建 额外 的 服务 以 及 “客户 协调 者 ”和 “供应 商 协 调 者 ”的 不 同 版 
Ж. “В”. “配送 订单 服务 ”以 及 “库存 服务 ”将 会 被 复 用 。 然 而 ， 需 要 新 的 服务 来 支 
F “RARP” (Contrat Service ) “发 货 单 服务 ”( Invoice Service) 以 及 “账户 可 支付 服务 ” 
(Accounts Payable Service )。 一 个 针对 电子 商务 软件 产品 线 的 可 复 用 的 面向 服务 的 体系 结构 由 
核心 的 、 可 选 的 以 及 变 体 构件 和 服务 组 成 ， 具 体 见 文献 Сотаа ( 2005a ) 所 述 。 
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第 23 章 | 


Software Modeling & Design: UML, Use Cases, Patterns, & Software Architectures 


基于 构件 的 软件 体系 结构 案例 研究 : 应 急 监 控 系 统 





本 章 描述 了 如 何 应 用 COMET 软件 建 模 和 体系 结构 设计 方法 开发 一 个 基于 构件 的 软件 体 
系 结构 ， 应急 监控 系统 。 

23.1 节 描 述 问 题 。23.2 节 描 述 “ 应 急 监控 系统 ”的 用 例 。23.3 节 描 述 “ 应 急 监 控 系 统 ” 
的 静态 模型 ， 包 括 系 统 上 下 文 和 实体 类 的 静态 建 模 。23.4 节 描 述 动态 建 模 以 及 每 个 用 例 的 通 
信 图 的 开发 过 程 。23.5 节 描 述 “ 应 急 监控 系统 ”的 设计 模型 ， 该 设计 模型 是 一 种 分 层 体系 结 
构 ， 综 合 应 用 了 抽象 层次 模式 、 客 户 端 / 服务 模式 以 及 一 些 体系 结构 通信 模式 。23.6 节 描 述 
软件 构件 的 部 署 。 


23.1 问题 描述 


“应 急 监 控 系 统 ” 包 含 一 些 远程 监控 系统 和 为 系统 提供 传感器 输入 的 监控 传感器 。 外 部 环 
境 状态 通过 各 种 传感器 进行 监控 。 一 些 传感器 属于 远程 监控 系统 ， 它 们 定期 发 送 存储 于 监控 
服务 的 监控 信息 。 另 外 ， 基 于 传感器 信息 ， 当 外 部 环境 发 生 未 预期 情况 时 发 出 警报 ， 这 些 警 
报 需要 人 来 处 理 。 警 报 存储 在 警报 服务 中 。 监 控 操 作 员 查 看 不 同 传感器 的 状态 并 且 查看 和 更 
新 警报 条 件 。 


23.2 用例 建 模 


本 节 描 述 “ 应 急 监 控 系 统 ” 的 用 例 模 型 。 根 据 问 题 描 述 可 以 确定 三 个 参与 者 。 系 统 中 有 
一 个 人 类 参与 者 “监控 操作 员 ”( Monitoring Operator )， 他 负责 发 起 查看 传感器 数据 和 警报 的 
用 例 。 此 外 ， 系 统 还 包括 一 个 外 部 输入 设备 参与 者 “监控 传感器 ”( Monitoring Sensor ) 以 及 
一 个 外 部 系统 参与 者 “远程 系统 ”( Remote System )。 这 两 个 参与 者 的 行为 类 似 ， 都 是 监控 远 
程 传感器 并 向 系统 发 送 传感器 数据 和 警报 。 这 种 相似 的 行为 可 以 通过 一 个 泛 化 的 参与 者 “ 远 
程 传感器 ”( Remote Sensor) 来 建 模 ， 它 表示 一 种 共同 的 角色 ， 即 “监控 传感器 ”和 “远程 系 
统 ” 这 两 个 特 化 的 参与 者 所 共有 的 行为 。 这 些 参 与 者 如 图 23-1 所 示 。“ 远 程 传 感 器 ”是 其 中 
两 个 用 例 的 主要 参与 者 。 

图 23-1 中 所 有 的 4 个 用 例 涉及 “监控 操作 员 ”， 作 为 主要 参与 者 或 者 次 要 参与 者 。 下 面 
对 各 个 用 例 进行 简要 介绍 : 

1) 查看 警报 (Мем Alarms )。“ 监 控 操 作 员 ”参与 者 查看 未 解决 的 警报 ， 确 认 造 成 警报 
的 原因 正在 处 理 中 。 操 作 员 还 可 以 订阅 或 者 退 订 某 种 特定 类 型 的 警报 通知 。 

2) 查看 监控 数据 ( View Monitoring Data )。“ 监 控 操 作 员 ” 参 与 者 请 求 查看 一 个 或 者 多 
个 传感器 的 当前 状态 。 这 种 操作 员 请 求 是 按 需 产生 的 。 操 作 员 还 可 以 订阅 或 者 退 订 监 控 状态 
的 变化 通知 。 

3 ) 生成 监控 数据 ( Generate Monitoring Data )。 监 控 数据 由 泛 化 的 参与 者 “远程 传 感 
器 ”不 间断 地 产生 。 操 作 员 获得 关于 他 们 所 订阅 的 监控 状态 事件 的 通知 。 

4) 生成 警报 (Generate Alarm )。 如 果 “ 远 程 传感器 ”检测 到 一 个 警报 条 件 被 满足 ， 那 
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么 系统 就 会 产生 一 个 警报 。 操 作 员 获 得 关于 他 们 所 订阅 的 警报 的 通知 。 


人 А View Monitoring Data 
Monitoring 
Operator 


T Remote 
Sensor 






Generate Monitoring Data 


Monitoring Remote 
Sensor System 


图 23-1 “应 急 监控 系统 ”的 用 例 和 参与 者 


23.2.1 “查看 监控 数据 ”用 例 描述 


用 例 名 称 : 查看 监控 数据 

概述 : 监控 操作 员 请 求 查看 一 个 或 者 多 个 位 置 的 当前 状态 
参与 者 : 监控 操作 员 

前 置 条 件 : 监控 操作 员 已 经 登录 

主 序列 : 


1. 监控 操作 员 请 求 查看 一 个 监控 位 置 的 状态 。 
2. 系统 按照 下 面 的 方式 显示 监控 状态 : 
每 个 传感器 的 传感器 状态 (ШИ, ER. FR. ERRE) 
ВУЗЕ]: 
步骤 2: 紧急 状况 。 系 统 向 操作 员 显 示 紧 急 状 况 警告 信息 
后 置 条 件 : 监控 状态 已 经 被 显示 


23.2.2 “查看 警报 ”用 例 描述 


用 例 名 称 : 查看 警报 
概述 : 监控 操作 员 查 看 未 解决 的 警报 ， 确 认 造 成 警报 的 原因 正在 处 理 中 


参与 者 : 监控 操作 员 
前 置 条 件 : 监控 操作 员 已 经 登录 
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主 序列 : 
1. 监控 操作 员 请 求 查 看 未 解决 的 警报 。 
2. 系统 显示 未 解决 的 警报 ， 对 于 每 个 警报 ， 系 统 显 示警 报名 称 、 警 报 描述 、 和 警报 


位 置 和 警报 严重 程度 (高 、 中 、 低 )。 
可 替换 序列 : 
步骤 2: 紧急 状况 。 系 统 向 操作 员 显 示 紧 急 状况 警告 信息 
后 置 条 件 : 未 解决 的 警报 已 经 被 显示 





23.2.3 “生成 监控 数据 ”用 例 描述 


用 例 名 称 : 生成 监控 数据 
概述 : 监控 数据 持续 产生 。 操 作 员 获得 关于 他 们 所 订阅 的 新 的 监控 状态 的 通知 
参与 者 : 远程 传感器 〈 主要 )、 监 控 操 作 员 (ХЕ) 
前 置 条 件 : 远程 系统 是 可 用 的 
主 序列 : 
1. 远程 传感器 发 送 新 的 监控 数据 给 系统 。 
2. 系统 按照 下 列 格 式 更 新 监控 状态 : 每 个 传感器 的 传感器 状态 〈 当前 值 、 上 限 、 
ТВ, ИХ). 
3. 系统 将 新 的 监控 状态 发 送 给 那些 订阅 接收 新 状态 更 新 的 监控 操作 员 。 
可 替换 序列 : 
步骤 2: 紧急 状况 。 系 统 向 操作 员 显 示 紧 急 状 况 警告 信息 
后 置 条 件 : 监控 状态 已 经 更 新 








23.24 “生成 警报 ”用 例 描述 


用 例 名 称 : 生成 警报 
概述 : 如 果 系 统 检测 到 某 个 警报 条 件 满足 就 会 产生 一 个 警报 。 操 作 员 接收 他 们 所 订 
阅 的 警报 通知 
参与 者 : 远程 传感器 (EE) MBAR (ХЕ) 
前 置 条 件 : 外 部 传感器 是 可 用 的 
主 序列 : 
1. 远程 传感器 发 送 一 个 警报 给 系统 。 


2. 系统 更 新 警报 数据 。 系 统 储 存 警 报名 称 、 警 报 描述 、 警 报 位 置 和 警报 严重 程 
BCR. №, (КА 
з. 系统 将 新 的 警报 数据 发 送 给 那些 订阅 接收 警报 更 新 的 监控 操作 员 。 
可 替换 序列 : 
$2: 紧急 状况 。 系 统 向 操作 员 显 示 紧 急 状况 警告 信息 
步骤 3: 如 果 警 报 严 重 ， 那 么 显示 闪烁 的 警报 
RAR: 警报 数据 已 经 更 新 
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233 HSER 
“应 急 监 控 系统 ”的 静态 建 模 由 软件 系统 的 上 下 文 类 图 组 成 。 外 部 类 可 以 通过 用 例 参与 者 


来 确定 ， 因 此 用 例 参 与 者 和 外 部 类 之 间 存 在 一 一 对 应 关系 。 
应 急 监 控 系统 上 下 文 类 «external user» 
ЕЕ 


上 下 文 类 图 定义 了 软件 系统 的 边界 。 
对 于 “应 急 监 控 系 统 ”( 见 图 23-2 )， 外 部 
类 包含 一 个 外 部 用 户 (“ 监 控 操 作 员 ”)、 一 
个 外 部 系统 (“远程 系统 ”) 和 一 个 外 部 输入 
设备 ( “监控 传感器 ” )。 由 于 每 个 外 部 类 都 
有 多 个 实例 ， 因 此 每 个 外 部 类 和 图 23-2 中 
的 “应 急 监控 系统 ”都 是 一 对 多 关联 。“ 远 
程 系统 ”和 “监控 传感器 ”的 公共 行为 是 通 = 


= Е РРА «external system» 


尽管 没有 必 -2 中 明确 描述 这 一 点 。 
入 没有 必要 在 图 23-2 PERRERA. 画 232 л н» 的 软件 系统 上 下 文 灶 图 


23.4 动态 建 模 


为 了 理解 系统 如 何 实现 用 例 ， 有 必要 分 析 “ 应 急 监控 系统 ”中 的 对 象 是 如 何 参与 用 例 的 。 
系统 的 动态 模型 使 用 通信 图 描述 。 共 有 4 个 通信 图 ， 每 个 用 例 对 应 于 其 中 一 个 。 由 于 对 象 / 
类 的 组 织 和 动态 建 模 是 迭代 性 的 活动 ， 因 此 本 章 对 二 者 都 进行 了 描述 。 前 者 在 23.4.1 节 描 述 ， 
后 者 在 23.4.2 到 23.4.6 节 描 述 。 由 于 事件 监控 不 是 状态 相关 的 ， 因 此 没有 状态 相关 的 控制 对 
象 ， 因 此 也 就 没有 状态 机 建 模 了 。 


23.4.1 类 和 对 象 组 织 


在 动态 建 模 过 程 中 ,我 们 首先 要 确定 参与 每 个 用 例 的 对 象 ， 然 后 分 析 对 象 之 间 的 交互 序 
列 。 第 一 步 是 分 析 如 何 将 “应 急 监控 系统 ”分 解 为 一 系列 类 和 对 象 。 

实体 类 通常 是 持久 化 类 ， 用 来 保存 信息 。“ 应 急 监控 系统 ”中 的 实体 类 包括 “警报 数据 仓 
库 ”(Alarm Data Repository ) 和 “监控 数据 仓库 ”( Monitoring Data Repository )， 这 是 因为 需 
要 保存 警报 数据 和 监控 数据 。 然 而 ， 实 体 类 被 封装 在 可 以 被 多 个 客户 端 访 问 的 服务 内 部 。 因 
此 ， 在 通信 图 中 ， 实 体 对 象 包含 在 服务 之 中 :“ 警 报 服 务 ”( Alarm Service) 和 “监控 数据 服 
务 ”( Monitoring Data Service )。 

对 于 每 一 个 人 类 参与 者 ， 都 需要 一 个 用 户 交 互 类 。 对 于 这 个 系统 ， 只 有 一 个 人 类 参与 者 ( 即 
“监控 操作 员 ”) 和 一 个 相应 的 用 户 交 互 类 ( 即 “ 操 作 员 交 互 ”( Operator Interaction ))。 因 为 操作 
员 使 用 多 窗口 界面 ， 所 以 有 两 个 支持 用 户 交 互 类 (“事件 监控 窗口 ”( Event Monitoring Window ) 
Al “ВИНЫ” (Alarm Window )) 来 分 别 显示 动态 更 新 的 状态 和 警报 信息 ( 见 23.5 77 )。 

此 外 ， 还 有 一 个 输入 对 象 ， 即 “监控 传感器 构件 ”( Monitoring Sensor Component )， 它 
从 外 部 监控 传感器 接收 传感器 输入 ， 然 后 将 状态 数据 发 送 给 “监控 数据 服务 ”对 象 ， 将 警报 
发 送 给 “警报 服务 ”对 象 。 还 有 一 个 代理 对 象 ， 即 “远程 系统 代理 ”( Remote System Proxy ), 
它 从 外 部 远程 系统 接收 传感器 数据 ， 同 时 将 状态 数据 发 送 给 “监控 数据 服务 ”对 象 ， 将 警 
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报 发 送 给 “警报 服务 ”对 象 。 最 后 ， 还 有 一 个 边界 父 类 ， 即 “远程 传感器 构件 ”( Remote 
Sensor Component )， 它 刻画 了 下 列 两 个 边界 子 类 的 公共 行为 :“ 监 控 传 感 器 构件 ”( Monitoring 
Sensor Component ) 和 “远程 系统 代理 ”( Remote System Proxy )。 图 23-3 描述 了 “应 急 监 控 
系统 ”的 类 组 织 ， 它 展示 了 将 对 象 实例 化 的 类 。 
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图 23-3 “应 急 监 控 系 统 ” 的 类 组 织 


23.4.2 用例 的 通信 图 


完成 对 象 的 组 织 之 后 进行 动态 建 模 ， 为 每 个 用 例 开发 通信 图 。 在 分 析 每 个 用 例 的 对 象 通 
信 过 程 中 ， 可 以 发 现在 后 续 设 计 过 程 中 可 能 会 用 到 的 各 种 体系 结构 模式 。 这 些 通信 图 之 中 有 
两 个 使 用 了 “多 客户 端 / 单 服务 ”模式 〈 见 第 15 章 )， 其 中 多 个 客户 端 实例 和 单个 服务 进行 
交互 。 另 外 两 个 通信 图 使 用 了 “订阅 /通知 ”模式 〈 见 第 17 章 )， 其 中 客户 端 接收 之 前 订阅 
的 一 个 客户 端 /服务 用 例 的 新 的 事件 通知 。 


23.4.3 “查看 警报 ”用 例 的 通信 图 


首先 考虑 “查看 警报 ”用 例 的 通信 图 ， 如 图 23-4 所 示 。 在 这 个 基于 “多 客户 端 / 单 服 
务 ” 模 式 的 场景 中 ， 客 户 端 能 够 请 求 查看 警报 或 者 订阅 未 来 的 警报 事件 通知 。 客 户 端 是 “ 操 
作 员 交互 ”对 象 ， 而 服务 则 是 由 “警报 服务 ”对 象 提供 的 。 消 息 序列 由 主要 参与 者 “监控 操 
作 员 ”的 输入 开始 ， 如 下 所 示 : 
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S1 :“ 监 控 操 作 员 ”请 求 一 个 警报 处 理 服 务 ， 例 如 查看 警报 或 者 订阅 特定 类 型 的 警报 
消息 。 


S1.1:“ 操 作 员 交互 ”发 送 警 报请 求 给 “警报 服务 ”。 


S1.2 :“ 和 警报 服务 ”执行 请 求 ( 例如 读 取 当前 警报 列表 或 者 将 这 个 客户 端 加 入 订阅 列 
表 )， 然 后 发 送 响 应 给 “操作 员 交 互 ” 对 象 。 
S1.3:“ 操 作 员 交互 ”对 象 显示 这 个 响应 ( 例如 警报 信息 ) 给 操作 员 。 


$1: Operator 


Request 
—> R А 
«user interaction» 
: OperatorInteraction 


: Monitoring 51.3: Display 
Operator Info 51.1: Alarm | 












Request | 51.2: Alarm Info 


«service» 
: AlarmService 


Е 23-4 “查看 警报 ”用 例 的 通信 图 
23.4.4 “查看 监控 数据 ”用 例 的 通信 图 


“查看 监控 数据 ”用 例 的 通信 图 ( 图 23-5 ) 也 使 用 了 “多 客户 端 / 单 服务 ”模式 ， 和 “ 查 
看 警报 ”用 例 的 通信 图 (图 23-4 ) 十 分 相似 。 客 户 端 仍然 是 “操作 员 交 互 ” 对 象 ， 而 服务 则 
由 “监控 数据 服务 ”对 象 提供 。 客 户 端 可 以 请 求 查 看 监控 数据 或 者 订阅 未 来 的 状态 事件 。 消 
息 序列 由 主要 参与 者 “监控 操作 员 ” 的 输入 开始 ， 如 下 所 示 : 


V1:“ 监 控 操 作 员 ”请 求 一 个 状态 监控 服务 ， 例 如 ， 查 看 某 个 监控 站 的 当前 状态 。 
V1.1:“ 操 作 员 交互 ”发 送 一 个 监控 状态 请 求 给 “监控 数据 服务 ”。 


V1.2:“ 监 控 数 据 服务 ”做 出 响应 ， 例 如 返回 所 请 求 的 监控 状态 数据 。 
V1.3:“ 操 作 员 交互 ”对 象 显示 监控 状态 信息 给 操作 员 。 





















V1: Operator 
Request 
«user interaction» 
: OperatorInteraction 
SSS 
V1.3: Display 
: Е Info V1.1: Monitoring V1.2: Monitoring 
Status Request Info 






«service» 
: MonitoringDataService 


图 23-5 “查看 监控 数据 ”用 例 的 通信 图 
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23.4.5 “生成 警报 ”用 例 的 通信 图 


考虑 “生成 警报 ”用 例 的 通信 图 ， 如 图 23-6 所 示 。 这 个 场景 使 用 了 “订阅 /通知 ” 模 

式 ， 其 中 新 的 警报 到 达 后 会 通知 相关 订阅 者 :“ 远 程 传感器 构件 ”( 代表 了 “监控 传感器 构件 ” 

和 “远程 系统 代理 ”的 公共 行为 ) 发 送 警报 给 “警报 服务 ”对 象 ， 然 后 该 对 象 通知 客户 端 对 
象 ( 本 例 中 是 “警报 窗口 ") 此 前 所 订阅 的 这 个 新 事件 。 消 息 序列 如 下 : 


:“ 远 程 传感器 构件 ” 收 到 外 部 传感器 的 输入 ， 表 明 某 个 警报 条 件 被 满足 。 
:“ 远 程 传感器 构件 ”发 送 警 报 给 “警报 服务 "。 


:“ 警 报 服务 ”向 所 有 订阅 了 这 类 消息 的 订阅 者 发 送 包含 这 个 警报 的 消息 。 
: “警报 窗口 ”接收 警报 通知 并 且 向 操作 员 显 示 信 息 。 


«external» 
: RemoteSensor 


у MI: Sensor Input 


«boundary» 
: RemoteSensorComponent 


| M2: Alarm 


«service» 
: AlarmService 


| M3: Alarm Notification 


М4: Display Info 
«user interaction» —> 
: Alarm Window 
: MonitoringOperator 


图 23-6 “生成 警报 ”用 例 的 通信 图 


















23.4.6 “生成 监控 状态 ”用 例 的 通信 图 


“生成 监控 状态 ”( Generate Monitoring Status ) 用 例 的 通信 图 也 使 用 了 “订阅 /通知 ” 

模式 ， 如 图 23-7 所 示 。 本 场景 中 ， 如 前 一 个 场景 那样 ,“ 远 程 传感器 构件 ”( 同 前 ， 代 表 

了 “监控 传感器 构件 ”和 “远程 系统 代理 ”的 共同 行为 ) 发 送 监控 状态 给 “监控 数据 服务 ” 

( Monitoring Data Service ) 对 象 ， 然 后 通知 客户 端 对 象 ( 本 例 中 是 事件 监控 窗口 ) 此 前 所 订阅 
的 这 个 新 事件 ， 消 息 序列 如 下 : 


N1:“ 远 程 传感器 构件 ” 收 到 外 部 远程 系统 的 传感器 输入 ， 表 示 监 控 状 态 发 生变 化 。 
N2:“ 远 程 传感器 构件 ”发 送 监控 数据 消息 给 “监控 数据 服务 "。 
N3:“ 监 控 数 据 服 务 ” 给 所 有 订阅 了 这 类 消息 的 订阅 者 发 送 包含 这 个 新 事件 通知 的 消息 。 


N4 :“ 事 件 监控 窗口 ”( Event Monitoring Window) 接收 事件 通知 消息 ， 并 且 把 信息 
显示 给 监控 操作 员 。 
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«external» 
: RemoteSensor 


| N1: Sensor Input 















«boundary» 
: RemoteSensorComponent 







| N2: Monitoring 
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: MonitoringOperator 


图 23-7 “生成 监控 状态 ”用 例 的 通信 图 


23.5 设计 建 模 


“应 急 监控 系统 ”的 软件 体系 结构 被 设计 成 一 个 基于 分 布 式 构件 的 软件 体系 结构 ， 它 使 用 
了 第 12、15 和 17 章 描 述 的 软件 体系 结构 模式 。“ 应 急 监 控 系统 ”被 设计 为 一 个 基于 抽象 分 层 
体系 结构 模式 的 分 层 体系 结构 。 


23.5.1 集成 的 通信 图 


设计 建 模 的 第 一 步 是 集成 四 个 基于 用 例 的 通信 图 以 生成 “应 急 监 控 系 统 ”的 集成 通信 和 图， 
其 中 描述 了 所 有 软件 对 象 ， 如 图 23-8 所 示 。 三 个 用 户 交 互 对 象 被 合并 为 一 个 复合 的 用 户 交互 
对 象 “ 操 作 员 展现 ”( Operator Presentation )， 其 中 包含 “警报 窗口 ”( Alarm Window )、“ 事 件 
监控 窗口 ”( Event Monitoring Window ) 和 “操作 员 交 互 ”( Operator Interaction) 对 象 。“ 操 
作 员 交互 ”与 “警报 服务 ”以 及 “监控 数据 服务 ”交互 ;“ 警 报 窗 口 ” 从 “警报 服务 ”接收 警 
报 通知 ;“ 事 件 监控 窗口 ”从 “监控 数据 服务 ”接收 事件 通知 。 特 化 的 边界 类 “监控 传感器 构 
件 ”( Monitoring Sensor Component ) 和 “远程 系统 代理 ”( Remote System Proxy ) 的 多 个 实例 
都 被 明确 描述 出 来 了 。 所 有 这 些 客户 端 对 象 都 和 “警报 服务 ”以 及 “监控 数据 服务 ”进行 通 
信 ， 分 别 发 送 警报 和 监控 数据 。 


23.5.2 ”基于 构件 的 分 层 体系 结构 


将 子 系统 组 织 准则 应 用 在 集成 通信 图 上 ， 可 以 确定 以 下 这 些 构件 和 服务 : 

• ARS: 包括 “警报 服务 "、 “监控 数据 服务 ”两 个 服务 。 

e 用 户 交 互 构件 。 用 户 交互 构件 包括 “操作 员 交 互 ” “警报 窗口 “事件 监控 窗口 ”， 
这 些 都 被 合并 到 一 个 复合 用 户 交互 对 象 中 ， 即 “操作 员 展 现 ”。 

e 代理 构件 。 代 理 构件 是 “远程 系统 代理 ”。 
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© 输入 构件 。 输 入 构件 是 “监控 传感器 构件 ”。 

每 个 构件 都 使 用 一 个 构件 构造 型 来 描述 ， 从 而 明确 它 的 构件 类 型 。 构 件 被 组 织 为 分 层 
体系 结构 ， 其 中 每 个 构件 都 被 放置 在 一 个 层次 中 ， 在 这 个 层次 上 该 构件 依赖 于 下 层 构 件 但 
不 会 依赖 于 上 层 构 件 。 这 种 分 层 体系 结构 是 基于 “灵活 的 抽象 分 层 ” 模 式 ， 是 “抽象 分 层 ” 
模式 的 一 种 约束 更 少 的 变 体 ， 其 中 每 个 层次 可 以 使 用 任何 较 低 层次 上 的 服务 而 不 仅仅 是 相 
邻 的 下 一 层 。 这 个 模式 的 主要 优势 在 于 它 为 未 来 的 软件 演化 提供 了 便利 ， 例 如 如 果 在 上 层 
增加 新 的 构件 〈 或 者 调整 这 些 层 次 的 构件 )， 那 么 下 层 的 用 户 服务 不 会 受到 影响 。 而 且 ， 最 
低层 可 以 增加 新 的 服务 ， 上 层 的 请 求 构件 可 以 发 现 这 些 服务 。 图 23-9 所 示 的 分 层 体系 结构 
描述 如 下 : 

层次 1: 服务 层 。 本 层 包含 “和 警报 服务 ”和 “监控 数据 服务 ”。 

层次 2 : 监控 层 。 本 层 包 含 “ 远 程 系统 代理 ”和 “监控 传感器 构件 "。 这 些 构 件 请 求 “ 服 
务 层 ”( Service Layer) 上 的 两 个 服务 。 

层次 3: 用 户 层 。 本 层 包 含 用 户 交 互 构件 “操作 员 展 现 ” 以 及 它 所 包含 的 构件 。 










«layer» 
UserLayer 


{层次 3} 


{层次 2} 





{层次 1? 








图 23-9 “应 急 监控 系统 ”的 分 层 体 系 结构 


如 果 两 个 层次 不 互相 依赖 ， 如 上 述 列表 中 的 第 2 层 和 第 3 层 ， 那 么 哪个 层次 更 高 是 一 个 
需要 考虑 的 设计 决策 。 除 了 “抽象 分 层 ” 体 系 结构 模式 ， 这 里 还 使 用 了 另 一 个 体系 结构 模式 : 
© 多 客户 端 / 多 服务 模式 。 这 个 体系 结构 中 有 多 个 “多 客户 端 /多 服务 ”模式 的 例子 。 
最 初 通过 基于 用 例 的 交互 图 可 以 被 识别 为 “多 客户 端 / 单 服务 ”模式 ， 因 为 每 个 客户 
端 只 和 一 个 服务 交互 。 而 集成 通信 图 ( 见 图 23-8) 则 表明 每 个 客户 端 ( 如 “远程 系统 
代理 ”) 实际 上 和 两 个 服务 (“警报 服务 ”和 “监控 数据 服务 ”) 交互 。 在 “抽象 分 层 ” 
体系 结构 中 ， 客 户 端 构件 被 设计 为 位 于 比 所 请 求 的 服务 更 高 的 层次 上 。 在 “灵活 的 
抽象 分 层 ” 模 式 中 ， 客 户 端 可 以 位 于 任意 的 更 高 层级 上 。 例 如 ,“ 操 作 员 展现 ”构件 
(一 个 客户 端 用 户 交互 构件 ) 在 第 3 层 上 ， 而 它 所 使 用 的 服务 (“警报 服务 ”和 “监控 

数据 服务 ”) WER 1 层 上 。 


23.53 ”体系 结构 通信 模式 
通信 图 明确 地 描述 了 通信 消息 的 类 型 





同步 或 者 异步 。 图 23-10 中 的 并 发 通信 图 展示 
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[465] 了 “应 急 监 控 系 统 ” 构 件 之 间 的 消息 通信 。 所 使 用 的 通信 模式 ( 见 第 12、15 和 17 Ж) 包括 
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g” 


式 ， 


“回复 的 同步 消息 通信 "、“ 异 步 消息 通信 ”和 “订阅 /通知 "。 此 外 还 使 用 了 “代理 者 和 发 





































模式 。 
[ 
«user interaction» 
«component» {53} 
: Operator 
Presentation 
alarmRequest 
(in request, out alarmData) 
alarmSubscribe (in request, 
in notificationHandle, out ack) 
П 
«input» У 
«componenb» {52} 
: MonitoringSensor 
Component 
post (event) monitoringRequest évent 
(in request, | Notify 
SA out monitoringData) (event) 
onitoringSubscribe (in request, 
in notificationHandle, out ack) 
alarmNotify (alarm) «service» 
: Monitoring {21} 







DataService 


Я 23-10 “应 急 监 控 系 统 ” 的 并 发 通信 图 


为 了 实现 软件 体系 结构 中 多 种 不 同 构件 间 的 通信 方式 ， 该 系统 的 设计 使 用 了 多 种 通信 模 

如 图 23-10 中 的 通信 图 所 示 : 

• 带 回 复 的 同步 消息 通信 。 这 个 模式 是 典型 的 客户 端 /服务 通信 模式 ， 当 客户 端 需要 服 
务 的 信息 并 且 不 能 在 获得 响应 之 前 继续 执行 的 时 候 使 用 这 种 模式 。 该 模式 使 用 在 用 户 
交互 客户 端 和 服务 器 之 间 ， 因 为 客户 端 需要 服务 响应 才能 继续 。 因 此 ， 它 使 用 在 “ 操 
作 员 展现 ”和 “警报 服务 ”之 间 ， 也 用 在 “操作 员 展 现 ” 和 “监控 数据 服务 ”之 间 
( 见 图 23-10 )。 

e 异步 消息 通信 。 "监控 传感器 构件 ”和 “远程 系统 代理 ”构件 通过 向 “警报 服务 ”发 
送 异 步 消息 来 传送 新 的 警报 。“ 监 控 传 感 器 构件 ”和 “远程 系统 代理 ”构件 也 发 送 异 
步 消息 给 “监控 数据 服务 ”( 如 图 23-10 )。 异 步 消 息 通信 模式 是 因为 “监控 传感器 构 
件 ” 和 “远程 系统 代理 ”构件 需要 定期 发 送 警 报 和 监控 状态 ; 它们 需要 无 延迟 地 继续 
执行 ， 而 且 不 需要 响应 。 

e 代理 者 句柄 。 代 理 者 模式 在 系统 初始 化 过 程 中 使 用 。 服 务 使 用 代理 者 注册 服务 信息 。 
“代理 者 句柄 ”模式 允许 客户 端 通过 查询 代理 者 来 确定 它们 应 该 连接 到 哪个 服务 。 

© 服务 发 现 .。“ 服 务 发 现 ”模式 允许 客户 端 发 现 服务 ， 这 使 得 系统 在 部 署 之 后 也 能 继续 演化 。 

e 订阅 /通知 (多 路 ).“ 操 作 员 展现 ”与 “警报 服务 ”以 及 “监控 数据 服务 ”有 两 种 通 
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信 模 式 ( 见 图 23-10 )。 第 一 个 是 客户 端 / 服 务 情形 中 常用 的 一 种 通信 模式 ， 即 “ 带 回 
复 的 同步 消息 通信 ”模式 ， 用 于 发 起 警报 请 求 并 接收 响应 。 第 二 个 是 “订阅 /通知 ” 
模式 ， 其 中 “操作 员 展 现 ” 构 件 订 阅 某 种 类 型 的 警报 (例如 高 优先 级 的 警报 )。 当 
“监控 传感器 构件 ”或 者 “远程 系统 代理 ”发 送 一 个 这 种 类 型 的 警报 给 “警报 服务 ” 
时 ， 服 务 会 通知 所 有 订阅 了 这 种 警报 的 “操作 员 展 现 ” 构 件 。“ 监 控 数据 服务 ”使 用 
了 相同 的 通信 方式 ， 其 中 客户 端 接收 的 是 监控 事件 通知 。 


23.54 基于 分 布 式 构件 的 软件 体系 结构 


图 23-11 描述 了 “应 急 监 控 系 统 ” 的 基于 分 布 式 构件 的 软件 体系 结构 ， 其 中 服务 已 经 被 
完全 集成 了 。 所 有 并 发 构件 和 服务 通过 端口 通信 。 这 些 端口 是 支持 供给 接口 的 供给 端口 或 者 
支持 请 求 接口 的 请 求 端口 。 没 有 同时 支持 供给 接口 和 请 求 接口 的 复杂 端口 。 接 口 在 随后 的 图 
里 进行 详细 描述 。 按 照 惯 例 ， 供 给 端口 名 称 以 P 为 前 缀 ( 如 PAlarmService )， 请 求 端 口 名 称 
以 R ARIA (如 RAlarmService )。 

“应 急 监 控 系 统 ” 的 软件 体系 结构 ( 图 23-11 ) 描述 了 两 个 服务 ， 每 个 都 支持 2 个 供给 端 
口 和 一 个 请 求 端口 。 两 个 客户 端 构 件 (“远程 系统 代理 ”和 “监控 传感器 构件 ”) 每 个 都 支持 
2 个 请 求 端口 。 第 三 个 客户 端 构件 “操作 员 展 现 ” 拥 有 2 个 请 求 端口 和 2 个 供给 端口 。 
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图 23-11 基于 分 布 式 构件 的 “应 急 监 控 系统 ”软件 体系 结构 






23.5.5 ”构件 和 服务 接口 设计 


23-12 到 图 23-15 描述 了 各 个 构件 和 服务 的 接口 设计 ， 其 中 描述 了 每 个 构件 / 服务 的 端 
口 和 接口 。 每 个 接口 都 按照 所 提供 的 操作 来 描述 ， 而 每 个 操作 则 描述 操作 和 名称、 输入 参数 和 
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图 23-12 “警报 服务 ”的 构件 接口 


首先 考虑 一 个 服务 及 其 端口 、 接 口 和 操作 的 例子 ， 同 时 考虑 与 这 个 服务 通信 的 客户 端 。 
“警报 服务 ”有 3 个 端口 ，PAlarmStatus、PAlarmService #1 RAlarmNotification ( 见 图 23-12 )。 
“警报 服务 ”有 2 个 供给 端口 ， 因 为 它 有 两 种 不 同类 型 的 客户 端 : 一 类 如 “操作 员 展 现 ”， 发 
出 同步 客户 端 / 服务 请 求 来 查看 数据 或 者 产生 订阅 请 求 ; 男 一 类 如 “监控 传感器 构件 ”， 异 步 
发 送 和 警报。 发 送 警 报 的 客户 端 使 用 PAlarmStatus 端口 ， 包 含 了 一 个 供给 接口 IAlarmStatus， 该 
接口 提供 了 一 个 操作 post (їп Alarm )。 发 送 需 要 响应 的 同步 请 求 的 客户 端 使 用 PAlarmService 
端口 ， 它 有 一 个 供给 接口 (IAlarmService )。 请 求 端口 RAlarmNotification 包含 一 个 请 求 接口 
IAlarmNotification ， 用 来 在 发 生 新 的 警报 后 向 客户 端 发 送 新 事件 通知 。 接 口 和 操作 规约 如 下 : 
ө 供给 接口 : IAlarmService 
操作 : 
• AlarmRequest ( in request, out alarmData ) 
• alarmSubscribe ( in request, in notificationHandle out ack ) 
• 供给 接口 : IAlarmStatus 
操作 : post (in alarm ) 
ө 请 求 接口 : IAlarmNotification 
操作 : alarmNotify (in alarm ) 
这 些 接口 的 使 用 方式 如 下 : 
• “操作 员 展 现 ”构件 (ILA 23-11) 通过 RAlarmService 请 求 端口 使 用 IAlarmService 请 
求 接口 〈 图 23-12 ) 来 向 “警报 服务 ”发 送 警 报请 求 和 订阅 请 求 。 
e“ 远 程 系统 代理 ”和 “监控 传感器 构件 ”( 见 图 23-11 ) 通过 RalarmStatus 请 求 端口 使 
用 IAlarmStatus 请 求 接口 ( 见 图 23-12) 来 向 “警报 服务 ”发 送 新 警报 。 
ө “警报 服务 ”( 图 23-11 和 图 23-12 ) 通过 RAlarmNotification 请 求 端口 使 用 LAlarmNotification 
请 求 接口 来 向 “操作 员 展 现 ”构件 发 送 警 报 通知 。 
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“监控 数据 服务 ”( 图 23-13) 的 设计 与 “警报 服务 ”相似 。 它 有 2 个 供给 接口 ， 一 个 连 
接 到 客户 端 “ 监 控 传 感 器 构件 ”和 “远程 系统 代理 ”的 请 求 接口 来 接收 新 事件 ; 另 一 个 连接 
到 “操作 员 展 现 ”构件 的 请 求 接口 来 接收 监控 请 求 。 它 有 一 个 请 求 接口 ， 连 接 到 “操作 员 展 
现 ” 构 件 的 供给 接口 来 发 送 通知 事件 。 
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Ра 23-13 “监控 数据 服务 ”的 构件 接口 


图 23-14 描述 了 3 个 客户 端 构件 。“ 远 程 系统 代理 ”和 “监控 传感器 构件 ”都 有 2 个 请 求 
端口 ， 每 个 端口 分 别 有 一 个 请 求 接口 ， 用 来 分 别 对 “监控 数据 服务 ”和 “警报 服务 ”发 送 事 
件 或 者 警报 。“ 操 作 员 展现 ”有 2 个 供给 端口 和 2 个 请 求 端口 ， 请 求 端口 用 来 与 “监控 数据 服 
务 ”以 及 “警报 服务 ”通信 。 供 给 端口 分 别 从 “监控 数据 服务 ”和 “警报 服务 ”接收 事件 和 [497 
警报 通知 。 469 
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Р 23-14 客户 端 构件 的 构件 接口 


“操作 员 展 现 ” 是 一 个 复合 构件 ， 包 含 3 个 简单 用 户 交 互 构件 〈 如 图 23-15 所 示 )， 分 别 
是 “操作 员 交 互 ”" “警报 窗口 ”和 “事件 监控 窗口 "。 考 虑 供给 端口 : 复合 “操作 员 展 现 ” 构 
件 的 供给 端口 直接 连接 到 内 部 构件 “警报 窗口 ”和 “事件 监控 窗口 ”的 供给 端口 上 。 连 接 
外 层 供 给 端口 和 内 层 供 给 端口 的 连接 器 叫做 委托 连接 器 ， 通 过 委托 连接 器 ， 由 “操作 员 展 
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现 ” 提 供 的 外 部 委托 端口 接收 消息 ， 然 后 转发 给 垦 套 构件 提供 的 内 部 端口 ， 例 如 “警报 窗 
п”. 按照 惯例 ， 这 两 个 端口 使 用 了 相同 的 名 称 ( 例如 “操作 员 展 现 ” 和 “警报 窗口 ”都 是 
PAlarmNotification )， 因 为 它们 提供 了 相同 的 接口 。 与 之 相似 ,“ 操 作 员 交互 ”构件 的 内 部 请 
求 端口 (RAlarmService #1 RmonitoringService ) 也 直接 连接 到 “操作 员 展 现 ” 相 同名 称 的 外 


部 请 求 端 口上 。 


«user interaction» 
«componenb> 
OperatorPresentation 


«user interaction» «user interaction» «user interaction» 
«сотролеп» «сотропепі» «сотропепі» 
AlarmWindow EventMonitoring Window OperatorInteraction 


PAlarm | PEvent ш ‚ RAlarm ш RMonitoring 
Notification Notification Service Service 





Palam PEvent RAlarm RMonitoring 
Notification Notification Service BOE 


图 23-15 用户 交 互 构件 的 构件 接口 


23.6 ”软件 构件 部 署 


一 个 典型 的 “应 急 监控 系统 ”的 软件 构件 部 署 图 如 图 23-16 所 示 。 每 一 个 客户 端 构件 
( 每 个 构件 都 有 多 个 实例 ) 和 每 一 个 服务 都 被 分 配 到 了 自己 的 物理 结 点 上 ， 如 图 23-16 所 示 。 
客户 端 构 件 包 括 “ 监 控 传 感 器 构件 ”( 每 个 监控 位 置 一 个 结 点 “远程 系统 代理 ”( 每 个 远 
程 系统 一 个 结 点 ) 和 “操作 员 展 现 ”( 每 个 操作 员 一 个 结 点 )。 服 务 包括 “监控 数据 服务 ”和 
“警报 服务 ”( 每 个 服务 一 个 结 点 )。 结 点 之 间 通 过 因特网 连接 。 


Monitoring Sensor 
Component 
{1 node per 
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Operator 
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Alarm Service 
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Е 23-16 “应 急 监 控 系 统 ” 的 部 署 图 
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实时 软件 体系 结构 案例 研究 : 自动 引导 和 车辆 系统 





“自动 引导 车 辆 系统 ”( Automated Guided Vehicle, AGV) 案例 研究 是 一 个 实时 系统 的 
例子 。 将 与 之 交互 的 其 他 系统 (“WE ABE” (Supervisory System) 和 “显示 系统 ”( Display 
System ) ) 一 起 考虑 的 话 ， 这 也 是 一 个 分 布 式 的 系统 之 系统 ( system of system) 的 例子 。 其 中 
“监管 系统 ”和 “显示 系统 ”是 现 有 的 系统 ， 而 АСУ 系统 需要 建立 与 这 两 个 系统 的 接口 。 

24.1 节 描 述 问题 。24.2 节 给 出 АСУ 系统 的 用 例 模 型 。24.3 节 介 绍 静 态 模型 ， 其 中 包 
括 用 于 描述 系统 与 外 部 环境 之 间 边 界 的 系统 上 下 文 模型 。24.4 节 描 述 АСУ 系统 的 对 象 组 
织 。24.5 节 描 述 动态 的 状态 机 建 模 。24.6 节 介 绍 动态 交互 建 模 ， 其 中 为 每 个 用 例 建立 了 通 
信 图 。24.7 节 介 绍 AGV 系统 的 设计 模型 ， 包 括 基于 构件 的 实时 软件 体系 结构 的 设计 。 


24.1 问题 描述 


基于 计算 机 的 AGV 可 以 在 工厂 内 部 按照 顺 时 针 方 向 在 轨道 上 移动 ， 并 且 在 工厂 内 各 个 
站 点 启动 和 停止 。AGYV 系统 具有 以 下 特点 : 

1) 一 个 发 动机 ， 可 以 按照 命令 启动 和 停止 车 辆 的 移动 。 发 动机 会 发 送 两 种 响应 :“ 已 启 
动 ”(Started ) 和 “已 停止 ”( Stopped )。 

2) 一 个 到 达 传 感 器 ， 用 于 检测 АСУ 何 时 到 达 一 个 站 点 ， 例 如 已 到 达 x 站 点 。 如 果 该 站 
点 是 目标 站 点 ， 则 АСУ 会 停止 。 反 之 АСУ 会 越过 该 站 点 继续 移动 。 

3) 一 个 机 械 臂 ， 用 于 装 货 和 伸 货 。 

АСУ 系统 从 外 部 “监管 系统 ”那里 接收 “移动 ”( Move ) 命令 ， 并 且 向 “监管 系统 ”发 
送 车 辆 “确认 信息 ”( Acks )， 以 表明 车 辆 已 启动 、 越 过 某 个 站 点 或 在 某 站 点 上 停止 。 此 外 ， 
АСУ 系统 还 会 每 隔 30 秒 向 “显示 系统 ”发 送 一 次 车 辆 状态 信息 。 

在 АСУ 系统 中 到 达 传 感 器 是 事件 驱动 的 输入 设备 ， 而 发 动机 和 机 械 臂 则 是 被 动 的 输入 / 
输出 (IO ) 设备 。 此 外 ，AGYV 系统 通过 消息 与 “监管 系统 ”和 “显示 系统 ”进行 通信 。 


242 用例 建 模 
АСУ 系统 的 用 例 模 型 如 图 24-1 所 示 。 从 问题 描述 可 知 ， 该 模型 包括 两 个 用 例 ， 其 中 一 


个 处 理 车 辆 移动 到 某 个 站 点 ， 另 一 个 用 例 负责 

将 车 辆 状态 发 送 至 显示 系统 。 其 中 包含 四 个 参 ees | з 
与 者 :“ 监 管 系统 ”( Supervisory System )、“ 显 ја Arrival S 
АСУ 系统 的 角度 来 说 ,“ 监 管 系统 ”和 “显示 T 
系统 ”是 外 部 系统 参与 者 。“ 到 达 传感器 ”是 0°" 


示 系 统 ”(Display System), “到 达 传 感 器 ”en 
Display System 
一 个 输入 设备 参与 者 ， 而 “时 钟 ”是 个 计时 器 图 24-1 自动 引导 车 辆 系统 : НЯ 










( Arrival Sensor) 以 及 “时 钟 ”(Clock )。 从 大 
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参与 者 。 下 面 给 出 用 例 描述 。 
24.2.1 “移动 到 站 点 ”用 例 


“监管 系统 ”是 发 起 “移动 到 站 点 ”( Move to Station ) 用 例 的 主要 参与 者 ， 因 为 该 系统 负 
责 发 送 移动 命令 给 АСУ 系统 -“ 到 达 传 感 器 ”会 在 车 辆 到 达 站 点 时 发 出 通知 ， 因 此 作为 次 要 
参与 者 参与 该 用 例 。 用 例 的 描述 如 下 : 


用 例 名 称 : 移动 到 站 点 
概述 : AGV 移动 部 件 到 工厂 站 点 
参与 者 : 监管 系统 ( 主 )， 到 达 传 感 器 (次 ) 
前 置 条 件 : AGV 是 静止 的 
主 序列 : 
1.“ 监 管 系统 ”发 送 消息 给 “AGYV 系统 ”， 要 求 移动 到 某 个 工厂 站 点 并 装载 一 个 部 件 。 


2. “AGV 系统 ”命令 发 动机 开始 移动 。 
3. 发 动机 通知 “AGYV 系统 ”车 辆 已 经 开始 移动 。 
4.“AGV 系统 ”发 送 “ 已 离开 ”的 消息 到 “监管 系统 ”。 
5. 到 达 传 感 器 通知 “AGYV 系统 ”已 经 到 达 工 厂 站 点 (#)。 
6. “АСУ 系统 ”确定 该 站 点 是 目标 站 点 并 命令 发 动机 停止 移动 。 
7. 发 动机 通知 “AGYV 系统 ”车 辆 已 经 停止 移动 。 
8. “АСУ 系统 ”命令 机 械 臂 装载 部 件 。 
9. 机 械 臂 通知“AGV 系统 ”部 件 已 经 装载 。 
10. “АСУ 系统 ”发 送 “ 已 到 达 ”( Arrived ) 消息 给 “监管 系统 ”。 
可 替换 序列 : 
SO: 如 果 车 辆 到 达 与 目标 站 点 不 同 的 站 点 ， 车 辆 将 继续 移动 越过 该 站 点 并 发 送 
消息 “越过 工厂 站 点 (#)” 给 “监管 系统 ”。 
第 8、9 步 : WR KERA AR AGV 移动 到 工厂 站 点 并 着 载 部 件 ，AGYV 将 会 在 
到 达 目 标 站 点 后 印 载 部 件 。 
后 置 条 件 : АСУ 完成 任务 并 到 达 目 标 站 点 。 





24.2.2 “发 送 车 辆 状态 ”用 例 


在 此 用 例 中 “时 钟 ”( Clock ) 是 主要 参与 者 ， 负 责 发 起 “发 送 车 辆 状态 ”用 例 ， 而 “ 显 
示 系 统 ”( Display System) 是 次 要 参与 者 。 用 例 描述 如 下 : 


用 例 名称 : 发 送 车 辆 状态 
概述 : АСУ 发 送 关 于 车 辆 位 置 和 空闲 /繁忙 状态 的 信息 给 显示 系统 。 
参与 者 : 时 钟 ( 主 )、 显 示 系 统 (次 ) 


前 置 条 件 : AGV 处 于 运行 状态 
主 序列 : 
1. 时 钟 通知 “AGYV 系统 ”计时 器 已 过 期 。 
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2. “AGV 系统 ” 读 取 关于 АСУ 位 置 和 空 闪 /繁忙 状态 的 信息 。 
3.“AGYV 系统 ”发 送 其 状态 信息 给 “显示 系统 ”。 





后 置 条 件 :“AGV 系统 ”已 经 发 送 状 态 信息 


24.3 ве 
本 节 描 述 静 态 模 型 包括 系 统 上 下 文 模型 和 实体 类 模型 。 474 
24.3.1 概念 静态 模型 


图 24-2 中 给 出 了 用 类 图 表示 的 概念 静态 模型 。 其 中 描述 了 一 个 系统 之 系统 ,包括 “监管 系 
Ж”. “АСУ 系统 ”和 “显示 系统 ”。“AGYV 系统 ”被 建 模 为 一 个 复合 类 ， 从 “监管 系统 ”接收 
命令 并 返回 确认 信息 ， 此 外 还 发 送 状 态 信息 给 “显示 系统 "。“AGYV 系统 ”由 四 个 类 组 成 :“ 到 
达 传 感 器 ”( Ата! Sensor )、“ 发 动机 ”( Motor )、“ 机 械 臂 ”( Robot Arm) 和 “时 钟 ”( Clock )。 





































Sends Commands to «system» Sends Status to 
«system» > Automated > «system» 
Supervisory fs А Display 
System 1 4 Sends 1 * Guided Vehicle System 


Acknowledge to System 


«output device» «output device» «timer» 
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图 24-2 “自动 引导 车 辆 系统 ”的 概念 静态 模型 
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Arrival 
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24.3.2 ”软件 系统 上 下 文 建 模 


软件 系统 上 下 文 类 图 ( 图 24-3 ) 是 从 被 开发 软件 系统 ( 即 “AGYV 系统 ”) 的 角度 建 模 的 。 
因此 ， 它 包括 两 个 外 部 系统 类 ( 即 “监管 系统 ”和 “显示 系统 ”) 以 及 作为 外 部 计时 器 类 的 
“时 钟 "，“ 时 钟 ”最 初 在 用 例 模型 中 被 描述 为 参与 者 。 此 外 还 有 一 个 外 部 输入 设备 类 “到 达 传 
感 器 ”和 两 个 外 部 输出 设备 类 “发 动机 ”和 “机 械 臂 ”。 
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Al 24-3 “自动 引导 车 辆 系统 ”的 软件 系统 上 下 文 类 图 475 
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244 ”对象 和 类 组 织 


“АСУ 系统 ”的 对 象 组 织 如 图 24-4 所 示 。 软 件 系统 上 下 文 类 图 中 的 每 个 外 部 类 都 有 个 
相对 应 的 内 部 软件 类 。 因 此 ， 存 在 两 个 代理 类 ， 即 “监管 系统 代理 ”( Supervisory System 
Proxy ) 和 “显示 代理 ”( Display Proxy )， 它 们 分 别 与 两 个 外 部 系统 通信 ， 即 “监管 系统 ” 
( Supervisory System ) 和 “显示 系统 ”( Display System )。 还 有 一 个 输入 类 “到 达 传 感 器 接口 ” 
( Arrival Sensor Interface )， 它 与 外 部 输入 设备 “到 达 传 感 器 ”( Arrival Sensor ) 进行 通信 ; 有 
两 个 输出 类 “发 动机 接口 ”( Motor Interface) 和 “机 械 臂 接口 ”( Arm Interface )， 分 别 与 两 
个 外 部 输出 设备 类 “发 动机 ”( Motor ) 和 “机 械 臂 ”( Arm ) 通信 。 此 外 ， 系 统 中 还 存在 两 个 
类 : 一 个 状态 相关 的 控制 类 “车 辆 控制 ”( Vehicle Control )， 负 责 执 行车 辆 状态 机 ; 一 个 实体 
类 “车 辆 状态 ”( Vehicle Status )， 其 中 包含 了 关于 车 辆 目的 地 和 命令 的 数据 。 最 后 ， 还 存在 


一 个 计时 器 类 “车 辆 计时 器 ”( Vehicle Timer )。 
Clock 
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И 24-4 “自动 引导 车 辆 系统 ”的 对 象 组 织 
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245 动态 状态 机 建 模 


“车 辆 控制 ”类 执行 车 辆 状态 机 ， 如 图 24-5 中 的 状态 图 所 示 。 状 态 机 涵盖 了 车 辆 从 空闲 
(idle) 状态 到 移动 、 到 达 目 的 地 、 装 载 或 卸载 部 件 以 及 重新 启动 等 各 种 状态 。 这 些 状态 可 以 
通过 分 析 “ 移 动 到 站 点 ”用 例 中 所 描述 的 主 序列 来 确定 ， 具 体 如 下 : 
ө 空闲 (Idle), 初始 状态 ， 此 时 АСУ 空闲 并 等 待 来 自 “监管 系统 ”的 命令 。 
• 启动 (Starting )。 当 AGV 接收 到 来 自 “ 监 管 系统 ”的 “移动 到 站 点 ”( Move to 
Station ) 消息 并 发 送 一 个 启动 命令 给 发 动机 后 进入 此 状态 。 
ө 移动 (moving) AGV 正在 向 下 一 个 站 点 移动 。 
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o 检查 目的 地 (Checking Destination), АСУ 到 达 一 个 站 点 并 正在 检查 以 确定 该 站 点 是 
否 是 目标 站 点 。 

e 停止 并 准备 装载 (Stopping to Load )。 当 前 站 点 为 目标 站 点 ，AGYV 准备 装载 部 件 。 
AGV 在 进入 此 状态 时 命令 发 动机 停止 。 

e 部 件 装载 ( Рап Loading )。 机 械 臂 正在 将 部 件 装 载 到 AGV Е. 

o 停止 并 准备 卸载 (Stopping to Unload )。 当 前 站 点 为 目标 站 点 ，AGYV HER ЖИД 
АСУ 在 进入 此 状态 时 命令 发 动机 停止 。 

o ВЕН ( Part Unloading )。 机 械 臂 正在 将 部 件 从 АСУ LHR ТЖ. 


Vehicle Control 
No / Passed 
Move to station / 

Start Motor, 


Store Destination Started / Arrived at Station / 


Departed Check Destination 
Checking 
Destination 


Load Command 
Stop Motor 


Stopped / Load Unload Command / 
Part Loading Stopping to Stop Motor 


Unloaded / 


Arrived, Clear 
К Stopped / Unload 
Part Unloading rt to 


РА 24-5 “自动 引导 车 辆 系统 ”的 状态 图 


注意 “停止 并 准备 装载 ”和 “停止 并 准备 卸载 ”这 两 个 状态 是 分 开 的 ， 因 为 离开 这 两 个 
状态 时 的 动作 是 不 同 的 (分 别 为 装载 和 种 载 )。 





24.6 动态 交互 建 模 


对 于 每 个 用 例 ， 我 们 都 要 开发 一 个 通信 图 以 描述 参与 用 例 的 各 个 对 象 以 及 对 象 之 间 传 递 
的 消息 序列 。 其 中 主要 的 用 例 “移动 到 站 点 ”( Move to Station) 由 多 个 对 象 共同 实现 ， 而 支 
持 用 例 “发 送 车 辆 状态 ”( Send Vehicle Status) 只 需要 三 个 软件 对 象 来 实现 。 


24.6.1 “移动 到 站 点 ”用 例 的 动态 建 模 


在 “移动 到 站 点 ”用 例 的 通信 图 中 (图 24-6 )， 外 部 输入 和 外 部 输出 的 顺序 与 用 例 中 所 
描述 的 顺序 一 致 ， 从 作为 主要 参与 者 的 “监管 系统 ”发 送 消 息 开 始 。 实 现 此 用 例 的 对 象 包括 : 
“监管 系统 代理 ”( Supervisory System Proxy )， 此 对 象 从 “监管 系统 ”接收 输入 ;“ 车 辆 控制 ” 
(Vehicle Control )， 负 责 控 制 参与 本 用 例 的 各 个 对 象 ; “车 辆 状态 ”( Vehicle Status )， 用 于 存储 
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和 检索 目的 地 位 置信 息 ;“ 机 械 臂 接口 ”( Arm Interface) 和 “发 动机 接口 ”( Motor Interface ), 
用 于 与 两 个 外 部 输出 设备 进行 交互 ;“ 到 达 传 感 器 接口 ”( Arrival Sensor Interface )， 用 于 从 到 
达 传 感 器 接收 输入 。 







«external input 
device» 
: ArrivalSensor 






«external system» 
: SupervisorySystem 











1: Move Command | 1 1.7, 2.5, 3.13: АСУ Ack 2, 3: Arrival Sensor Input | 





«software 
system» 

: Automated 
GuidedVehicle 
System 









«proxy» 
: SupervisorySystem 
Proxy 












«input» 
: ArrivalSensor 
Interface 


























1.6: Departed, 
2.4: Passed, 

3.12: Arrived 2.1, 3.1: Arrived at Station 
= 








1.2a: Store Destination, 
2.2, 3.2: Check Destination, 
3.12a: Clear 











1.1: Move to Station 





«state dependent 
control» 
: VehicleControl 


«entity» 
: Vehicle 







3.8: Load, 
3.8A: Unload 







3.11: Loaded, 1.2: Start Motor, 
3.11A: Unloaded 3.4: Stop Motor 









«output» «output» 
:Arm : Motor 


Interface 


у 


«external output 
device» 
: Motor 







Interface 















1.3: Start Motor Output, 
3.5: Stop Motor Output 


1.4: Started Ack, 


9: 3.10: Агт Аск 
3.9: Arm Output | | а 3.6: Stopped Ack 







«external 
output device» 
:Arm 








Е 24-6 “移动 到 站 点 ”用 例 的 通信 图 
在 下 述 场景 中 ， 车 辆 经 过 第 一 个 站 点 并 且 停 在 第 二 个 站 点 上 以 装载 部 件 ， 其 消息 序列 为 : 


1: 外 部 “监管 系统 ”向 “AGV 系统 ”发 送 “ 移 动 ”命令 ， 要 求 车 辆 移动 到 一 个 工厂 
站 点 并 装载 部 件 。 

1.1:“ 监 管 系统 代理 ”接收 “移动 ”命令 ， 发 送 “ 移 动 到 站 点 ”命令 给 “车 辆 控制 "。 

1.2:“ 车 辆 控制 ”发 送 “启动 发 动机 ”命令 给 “发 动机 接口 ”以 开始 移动 。 


1.2a: “车 辆 控制 ”在 “车 辆 状态 ”中 保存 目标 站 点 以 及 装载 / 卸载 命令 。 
1.3:“ 发 动机 接口 ”发 送 “启动 发 动机 ”( Start Motor) 命令 给 外 部 “发 动机 ”。 
1.4:“ 发 动机 ”发 送 “ 启 动 ” 确 认 信 息 给 “发 动机 接口 "。 

1.5:“ 发 动机 接口 ”通知 “车 辆 控制 ”车 辆 已 经 开始 移动 。 
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1.6:“ 车 辆 控制 ”发 送 “ 离 站 ”消息 给 “监管 系统 代理 ”。 

1.7:“ 监 管 系统 代理 ”将 “ 离 站 ”( Departed ) 消息 转发 给 “监管 系统 ”。 

2: 到 达 传 感 器 通知 AGV 系统 已 经 到 达 工 厂 站 点 (#)。 

2.1:“ 到 达 传 感 器 接口 ”发 送 “ 到 达 站 点 ”( Arrived at Station) 消息 给 “车 辆 控制 ”。 
2.2:“ 车 辆 控制 ”发 送 “ 检 查 目 的 地 ”( Check Destination ) 消息 给 “车 辆 状态 ”对 象 。 
2.3:“ 车 辆 状态 ”对 象 指示 此 站 点 不 是 目的 地 站 点 。 

2.4:“ 车 辆 控制 ”发 送 “ 继 续 移 动 ”( Passed ) 的 消息 给 “监管 系统 代理 ”。 
2.5:“ 监 管 系统 代理 ”将 “继续 移动 ”的 消息 转发 给 “监管 系统 ”。 

3: 到 达 传 感 器 通知 “AGV 系统 ” 它 已 经 到 达 工 厂 站 点 (#)。 

3.1:“ 到 达 传 感 器 接口 ”发 送 “ 到 达 站 点 ”消息 给 “车 辆 控制 ”。 

3.2:“ 车 辆 控制 ”发 送 “ 检 查 目标 站 点 ”消息 给 “车 辆 状态 ”对 象 。 

3.3:“ 车 辆 状态 ”对 象 指示 此 站 点 为 目标 站 点 ， 并 表明 所 接 到 的 命令 是 装载 部 件 。 
3.4:“ 车 辆 控制 ”发 送 “ 停 止 发 动机 ”消息 给 “发 动机 接口 ”。 

3.5:“ 发 动机 接口 ”发 送 “ 停 止 发 动机 ”命令 给 外 部 “发 动机 ”设备 。 

3.6:“ 发 动机 ”发 送 “ 停 止 ” 确 认 消 息 给 “发 动机 接口 ”。 

3.7:“ 发 动机 接口 ”通知 “车 辆 控制 ”车 辆 已 经 停止 移动 。 

3.8:“ 车 辆 控制 ”发 送 “ 装 载 ”(Load ) 消息 给 “机 械 臂 接 口 "。 

3.9:“ 机 械 民 接口 ”发 送 “装载 ”消息 给 外 部 “机 械 展 ”设备 。 

3.10:“ 机 械 避 ”发 送 确 认 消 息 给 “车 辆 控制 ”并 表明 机 械 辟 已 完成 装载 。 
3.11:“ 机 械 避 接口 ”发 送 “ 已 装载 ”( Loaded ) 消息 给 “车 辆 控制 ”。 

3.12:“ 车 辆 控制 ”发 送 “ 到 达 ” 消 息 给 “监管 系统 代理 ”。 

3.13:“ 监 管 系统 代理 ”转发 “到 达 ” 消 息 给 “监管 系统 ”。 





“车 辆 控制 ”发 出 和 接收 的 消息 与 图 24-7 中 所 描述 的 状态 图 中 的 事件 和 动作 相对 应 ， 并 
且 遵 循 与 此 前 的 消息 序列 描述 中 一 样 的 场景 。 480 


Vehicle Control 


1.1 Move to station / 
1.2: Start Motor, 
1.2a: Store Destination 1.5: Started / 


1.6; Departed 
Starting 


2.3: Мо / 2.4: Passed 


2.1, 3.1: Arrived at Station / 
2.2, 3.2: Check Destination 


3.3: Load Command / 


3.11: Loaded / 3.4: Stop Motor 
3.12: Arrived, 
3.12a: Clear 


3.7; Stopped / 3.8: Load рЫ Ори 
Part Loading ор Motor 


Unloaded / 


Arrived, Clear Stopped / Unload Stopping to 
Part Unloading Unload 


图 24-7 “车 辆 控制 ”状态 图 中 的 事件 和 动作 序列 编号 481 
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24.6.2 “发 送 车 辆 状态 ”用 例 的 动态 建 模 


“发 送 车 辆 状态 ”用 例 的 通信 图 如 图 24-8 所 示 。 实 现 此 用 例 的 对 象 包括 :“ 车 辆 计时 器 ” 
(Vehicle Timer )， 人 负责 接 收 时 钟 输入 ;“ 车 辆 状态 ”( Vehicle Status )， 用 于 保存 状态 信息 ;“ 显 
示 代 理 ”( Display Proxy )， 负 责 发 送 车 辆 状态 给 外 部 “显示 系统 ”。 用 例 的 消息 序列 由 来 自 于 
外 部 的 “时 钟 ” 对 象 的 计时 器 事件 发 起 ， 消 息 序列 如 下 : 


1:“ 时 钟 ” 发 送 “ 计 时 器 事件 ”给 “车 辆 计时 器 ”。 
1.1，1.2:“ 车 辆 计时 器 ” 读 取 “车 辆 状态 ”。 


1.3:“ 车 辆 计时 器 ”发 送 “ 更 新 状态 ”消息 给 “显示 代理 ”。 
1.4:“ 显 示 代 理 ” 发 送 “ 车 辆 状态 ”给 外 部 “显示 系统 ”。 





24.7 设计 建 模 
“AGYV 系统 ”的 软件 体系 结构 设计 遵循 集中 式 控制 模式 。 集 中 式 控制 由 “车 辆 控制 ” 构 


件 提供 ， 此 构件 从 “监管 系统 ”和 “到 达 传 感 
器 ”接收 输入 ， 控 制 外 部 环境 中 的 “发 动机 ” 
у 1: Timer Event 











和 “机 械 臂 "。 从 更 大 的 工厂 自动 化 系统 的 角度 
看 ， 其 体系 结构 的 设计 符合 层次 化 控制 模式 ， 
其 中 多 个 “AGYV 系统 ”的 实例 ( 每 个 实例 控制 
一 个 车 辆 ) 在 “监管 系统 ”的 控制 下 运行 ,，“ 监 
管 系统 ”通过 发 送 移 动 命 令 给 每 个 车 辆 提供 层 
次 化 的 控制 。 


2471 集成 通信 图 


在 设计 模型 的 初始 阶段 ， 需 要 开发 AGV 
系统 的 集成 通信 图 ， 为 此 需要 将 图 24-6 和 
图 24-8 中 给 出 的 两 个 基于 用 例 的 通信 图 进 
行 集成 。 图 24-9 给 出 了 集成 的 通信 图 。 此 例 | 14AGv Status 
中 的 集成 非常 简单 ， 因 为 参与 两 个 基于 用 例 的 
通信 图 中 只 有 一 个 共有 对 象 ， 即 “车 辆 状态 ” 


: DisplaySystem 
(Vehicle Status )。 集 成 通信 图 是 一 种 用 于 描述 


各 个 对 象 之 间 所 有 可 能 通信 的 泛 化 的 通信 图 。 图 24-8 “发 送 车 辆 状态 ”用 例 的 通信 图 
247.2 ”基于 构件 的 工厂 自动 化 系统 软件 体系 结构 

“工厂 自动 化 系统 ”的 分 布 式 软件 体系 结构 是 一 个 系统 之 系统 ， 如 图 24-10 中 的 系统 通 
信 图 所 示 。 图 中 显示 了 三 个 相交 互 的 分 布 式 系统 (设计 为 构件 ) :“ 监 管 系统 ”( Supervisory 


System ) “自动 引导 车 辆 系统 ”(AGV ) “ERRA” (Display System )。 其 中 包含 一 个 “ 监 
管 系统 ”的 实例 、 多 个 “AGYV 系统 ”和 “显示 系统 ”的 实例 。 所 有 分 布 式 构件 之 间 的 通信 均 






«software 
system» 

: Automated 
GuidedVehicle 
System 











«timer 
: VehicleTimer 





1.1: Read 






AA 


1.2: Status 





у 1.3: Update Status 


«proxy» 
: DisplayProxy 







«entity» 
: VehicleStatus 
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为 异步 的 ， 这 为 消息 通信 提供 了 极 大 的 灵活 性 。“ 监 管 系统 ”和 “AGYV 系统 ”之 间 的 通信 是 
一 个 双向 异步 通信 的 例子 。 


«external system» 
: SupervisorySystem 
Move Command || ^ 


«software 














«external input 
device» 
: ArrivalSensor 






«external timer» 
: Clock 


| Timer Event 












Arrival Sensor Input ( 
























system» «proxy» «input» 
: Automated : SupervisorySystem ; ArrivalSensor 
GuidedVehicle 






Interface 









« тег» 
: VehicleTimer| 


/ 


System 





Arrived at Station 






Store Destination, 
Check Destination, 
Clear 


















«state dependent —> «entity» 
control» : Vehicle d 
: VehicleControl Status Update Status 













Started, No, 
Stopped Load Command, 
Unload Command 

























Start Motor, 






Unloaded Stop Motor 
«output» «output» 
: Arm : Motor «proxy» 
Interface Interface : DisplayProxy 









Started Ack, 
Stopped Ack 











Arm Output [ 


Агт Аск Start Motor Output, 
Stop Motor Output 


J АСУ Status 

















«external 
«external output 
output device» device» «external system» 
i : Motor : DisplaySystem 





E 24-9 “自动 引导 车 辆 系统 ”的 集成 通信 图 








«component» 
«coordinator» 
SupervisorySystem 





«component» 
«coordinator» 
: SupervisorySystem 


RAGVSystem 


PAGVSystem 





























«component» PDisplaySystem component 
рева бозорот. ` ne E tad С) шег Interactions 
| | ui DisplaySyst 
тит : DisplaySystem VehicleSystem || RDisplaySystem РСЕ 


24-10 “工厂 自动 化 系统 ”的 系统 通信 图 图 24-11 基于 构件 的 “工厂 自动 化 系统 ”软件 体系 结构 


图 24-11 描述 了 基于 构件 的 “工厂 自动 化 系统 ”软件 体系 结构 ， 其 中 三 个 系统 设计 为 分 
HRH “AGV 系统 ”拥有 一 个 用 于 从 “监管 系统 ”接收 消息 的 供给 端口 (provided рог!) 
和 一 个 用 于 发 送 消息 给 “显示 系统 ”的 请 求 端口 (required port )。 供 给 端口 PAGVSystem 是 
一 个 复杂 端口 ， 因 为 它 同时 拥有 一 个 用 于 接收 命令 消息 的 供给 接口 [AGVSystem 以 及 一 个 用 
于 发 送 确 认 消 息 的 请 求 接口 ISupervisorySystem， 如 图 24-12 所 示 。 请 求 端口 RDisplaySystem 
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支持 一 个 请 求 接口 IDisplaySystem， 用 于 发 送 АСУ 状态 消息 给 “显示 系统 "”。 这 三 个 构件 接 
口 也 在 图 24-12 中 进行 了 定义 。 










«component» 
«coordinator» 
SupervisorySystem 





RAGVSystem 


О 
ISupervisorySystem |AGVSystem 


ISupervisorySystem lAGVSystem 
O 








PAGVSystem 










\DisplaySystem PDisplaySystem «component» 
О O—_]«user interaction» 
AutomatedGuided IDisplaySystem 


VehicleSystem | RoistaySystom 


«interface» «interface» «interface» 
ISupervisorySystem IAGVSystem IDisplaySystem 
= a eS Ee 
AGVAck (in status) moveCommand (in command) displayAGVStatus (in AGVStatus) 


Е 24-12 “工厂 自动 化 系统 ”的 复合 构件 端口 和 接口 


“工厂 自动 化 系统 ”的 配置 在 图 24-13 的 部 署 图 中 进行 了 描述 ， 其 中 每 个 “监管 系统 ”都 
有 一 个 结 点 ， 每 个 “显示 系统 ”也 有 一 个 结 点 ， 而 每 个 AGV 系统 均 对 应 于 一 个 独立 的 结 点 。 
工厂 内 部 的 分 布 式 结 点 之 间 通 过 局 域 网 连接 。 


| DisplaySystem 










SupervisorySystem 
{1 node} 









«local area network» 







AutomatedGuided 


DisplaySystem 
VehicleSystem ы 


AEE E, 
{1 node} | 
{1 node per AGV} 


Р 24-13 “工厂 自动 化 系统 ”的 分 布 式 系统 部 署 


247.3 自动 引导 车 辆 系统 的 软件 体系 结构 


“АСУ 系统 ”被 设计 成 实时 的 基于 构件 的 软件 体系 结构 。 基 于 构件 的 设计 遵循 第 17 章 所 
介绍 的 概念 ， 其 优点 是 可 配置 性 。 实 时 设计 是 由 于 应 用 本 身 的 特点 ， 它 遵循 第 18 章 中 所 介绍 
的 并 发 任务 组 织 准则 和 基于 消息 的 任务 接口 设计 。 

“АСУ 系统 ”的 设计 基于 实时 设计 的 集中 式 控制 模式 ( 见 第 18 章 )， 其 中 一 个 控制 构件 
“车 辆 控制 ”( Vehicle Control) 提供 对 整个 系统 的 控制 。 此 外 ,“AGYV 系统 ”被 设计 成 基于 构 
件 的 分 布 式 软件 体系 结构 ， 这 种 设计 允许 输入 输出 构件 驻 留 在 不 同 的 结 点 上 ， 而 这 些 结 点 之 
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间 通 过 高 速 总 线 相连 。 在 系统 部 署 时 需要 确定 所 采用 的 配置 类 型 〈 集 中 式 或 分 布 式 )。 

“АСУ 系统 ”的 并 发 软件 体系 结构 是 在 集成 通信 图 基础 上 开发 的 。 其 中 ， 并 发 任务 是 通 
过 应 用 任务 结构 化 组 织 准则 设计 的 ， 而 任务 之 间 的 消息 通信 和 是 通过 应 用 体系 结构 通信 模式 设 
计 的 。 随 后 设计 基于 构件 的 软件 体系 结构 。 最 后 描述 每 个 构件 的 供给 接口 和 请 求 接口 。 每 个 
构件 端口 则 在 供给 接口 和 /或 请 求 接口 之 上 定义 。 


2474 并 发 软件 体系 结构 


在 并 发 实时 设计 中 ， 并 发 任务 结构 化 组 织 准 则 被 用 于 确定 “AGYV 系统 ”的 各 个 任务 。 并 

发 任务 的 设计 (ILE 22-14) 从 图 24-9 给 出 的 集成 通信 图 开始 ， 图 中 描述 了 “AGYV 系统 ”的 

所 有 对 象 。 由 于 这 些 对 象 需要 独立 操作 ， 因 而 它们 是 并 发 的 ， 除 了 作为 被 动 数据 抽象 对 象 

的 “车 辆 状态 ”"。 由 于 设计 目标 是 基于 构件 的 并 发 软件 体系 结构 ， 因 此 任务 被 设计 为 简单 并 

发 构件 ， 每 个 构件 中 包含 一 个 简单 控制 线程 。 因 而 在 设计 中 ， 术 语 任务 (task) 和 简单 构件 

(simple component ) 是 同义词 。 并 发 任务 描述 如 下 : 

© 输入 任务 。 并 发 输入 任务 从 外 部 环境 接收 输入 并 发 送 相应 消息 给 控制 任务 。“ 到达 传 
感 器 构件 ”( 图 24-14 ) 被 设计 为 事件 驱动 的 输入 任务 ， 会 被 到 来 的 到 达 传 感 器 输入 唤 
醒 。 输 入 任务 由 分 析 模 型 ( 见 图 24-9 ) 中 各 个 输入 设备 接口 对 象 组 成 :“ 到 达 传 感 器 
#20”. 

e 代理 任务 -“ 监 管 系统 代理 ”代表 “监管 系统 ”运行 ， 从 “监管 系统 ”那里 接收 “ 移 

动 ”命令 并 转发 给 “车 辆 控制 ”任务 ， 并 且 向 “监管 系统 ”发 送 АСУ 确认 消息 。“ 监 

管 系统 代理 ”被 设计 成 事件 驱动 任务 ， 由 来 自 外 部 “监管 系统 ”或 内 部 “车 辆 控制 ” 

的 消息 唤醒 。 值 得 注意 的 是 ， 如 果 一 个 任务 不 仅 接收 外 部 消息 而 且 还 接收 内 部 消息 ， 

则 该 任务 被 设计 成 事件 驱动 任务 而 非 按 需 驱动 任务 “显示 代理 ”( Display Proxy ) 在 

“显示 系统 ”一 端 执 行 操作 ， 负 责 将 AGV 状态 消息 转发 给 “显示 系统 ”。“ 显 示 代 理 ” 

被 设计 成 按 需 驱 动 任务 ， 由 来 自 于 “车 辆 计时 器 ”的 消息 唤醒 。 

控制 任务 。“ 车 辆 控制 ”任务 是 “AGYV 系统 ”的 一 个 集中 式 状态 相关 的 控制 任务 。 该 

任务 执行 “车 辆 控制 ”状态 机 ， 从 其 他 包含 能 够 引起 “车 辆 控制 ”状态 变化 的 事件 的 

任务 接收 消息 ， 并 且 发 送 动作 消息 给 其 他 任务 -“ 车 辆 控制 ”任务 被 设计 成 按 需 驱动 

任务 ， 由 来 自 于 “监管 系统 代理 ”和 “到 达 传感器 构件 ”的 消息 唤醒 。 

e 输出 任务 。“ 机 械 臂 构件 ”与 外 部 “机 械 臂 ”项 链 。 在 分 析 模 型 中 “机 械 臂 接口 ”对 
象 被 映射 为 输出 任务 ( 见 图 24-9 和 图 24-14 )。 与 之 相似 ,“ 发 动机 构件 ”与 外 部 “发 
动机 ”交互 ， 在 分 析 模 型 中 发 动机 构件 被 设计 为 “发 动机 接口 ”对 象 。 两 个 输出 任务 
都 被 设计 为 按 需 驱 动 任务 ， 由 来 自 于 “车 辆 控制 ”任务 的 消息 按 需 唤 醒 。 


24.7.5 体系 结构 通信 模式 


图 24-14 ЈЕ “АСУ 系统 ”的 并 发 通信 图 ， 其 中 显示 了 АСУ 软件 体系 结构 中 的 并 发 任务 。 
接 下 来 进行 任务 接口 的 设计 。 

在 АСУ 系统 中 各 个 任务 之 间 的 消息 本 身 根据 图 24-9 的 集成 通信 图 确定 ,但 消息 通信 的 
类 型 ( 同步 或 异步 ) 依然 需要 进一步 明确 。 为 了 处 理 “AGYV 系统 ”中 任务 之 间 各 种 不 同 的 消 
息 通 信和 方式 ， 我 们 使 用 了 四 种 通信 模式 : 
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1) 异步 消息 通信 。“ 异 步 消息 通信 ”模式 在 “AGYV 系统 ”中 得 到 了 广泛 使 用 ， 这 是 因为 
系统 中 的 大 部 分 通信 是 单 向 的 ， 而 且 此 模式 的 一 个 优势 是 消息 生产 者 无 需 为 消息 消费 者 挂 起 。 
“车 辆 控制 ”任务 需要 从 两 个 消息 生产 者 〈( 即 “监管 系统 代理 ”和 “到 达 传 感 器 构件 ”) 接收 
消息 而 不 论 其 顺序 。 为 了 灵活 性 ， 处 理 此 需求 的 最 佳 方法 是 通过 异步 消息 通信 ， 其 中 为 “车 
辆 控制 ”任务 建立 一 个 输入 消息 队列 ， 从 而 使 “车 辆 控制 ”任务 可 以 处 理 首先 到 达 的 消息 ， 
不 论 是 移动 命令 还 是 到 站 通知 。“ 车 辆 计时 器 ”任务 发 送 异 步 的 AGYV 状态 消息 给 “显示 代理 ” 
任务 ， 而 “显示 代理 ”同样 通过 消息 队列 接收 这 些 消 息 。 

2) 双向 异步 通信 。 此 通信 模式 用 在 “监管 系统 代理 ”与 “车 辆 控制 ”任务 之 间 ， 这 是 由 
于 在 “监管 系统 代理 ”发 送 移动 命令 给 “车 辆 控制 ”任务 与 “车 辆 控制 ”任务 发 回 确认 消息 
之 间 可 能 需要 相当 长 的 一 段 时 间 (确认 发 生 在 АСУ 到 达 目 标 站 点 之 后 )。 因 此 ， 移 动 命令 和 
确认 消息 之 间 不 存在 耦合 。 

3) 不 带 回复 的 同步 消息 通信 。 当 消息 生产 者 需要 在 继续 执行 之 前 确认 消息 消费 者 已 经 接 
收 到 消息 时 需要 使 用 此 模式 。 在 本 章 的 实例 中 ， 此 通信 模式 用 在 “车 辆 控制 ”和 “机 械 臂 构 
件 ” 以 及 “车 辆 控制 ”和 “发 动机 构件 ”之 间 。 这 两 种 情形 下 消费 者 任务 会 保持 空闲 直到 接 
收 到 消息 ， 因 此 消息 生产 者 “车 辆 控制 ”任务 发 送 消息 后 无 需 等 待 确认 。 

4) 调用 /返回 。 当 “AGYV 控制 ”和 “车 辆 计时 器 ”调用 被 动 “车 辆 状态 ”数据 抽象 对 
象 时 使 用 ( 见 图 24-14 )。 


24.7.6 ”基于 构件 的 软件 体系 结构 


基于 构件 的 “AGYV 系统 ”体系 结构 如 图 24-15 所 示 。 图 中 显示 了 一 个 包含 系统 构件 端 
口 和 连接 器 的 UML 复合 结构 图 。 除 一 个 构件 之 外 所 有 其 他 构件 都 是 并 发 的 ， 构 件 之 间 通 过 
端口 进行 通信 。 系 统 的 整体 结构 以 及 构件 之 间 的 连接 在 “AGYV 系统 ”的 并 发 通信 图 的 基础 
上 确定 。 因 此 ， 图 24-15 所 示 的 构件 系 结构 的 复合 结构 图 是 基于 图 24-14 所 示 的 并 发 通信 图 
确定 的 。 

“自动 引导 车 辆 系统 ”构件 被 设计 为 包括 8 个 简单 部 分 构件 的 复合 构件 。 这 些 部 分 构件 
中 有 7 个 是 并 发 构件 ， 包 括 “ 监 管 系统 代理 ““ 到 达 传 感 器 构件 “车 辆 控制 “车 辆 计时 
器 ”、“ 机 械 臂 构件”"、“ 发 动机 构件 ”和 “显示 代理 ”; 此 外 还 有 一 个 被 动 的 数据 抽象 对 象 ， 即 
“车 辆 状态 ”。7 个 简单 并 发 构件 与 24.7.4 节 确 定 的 任务 相对 应 ， 并 在 图 24-14 的 并 发 通信 图 中 
给 出 。 

图 24-15 描述 了 如 何 将 “AGYV 系统 ”构件 分 解 成 上 一 段 提 到 的 7 个 简单 并 发 构件 和 1 个 
被 动 数据 抽象 对 象 。“AGYV 系统 ”复合 构件 的 供给 端口 直接 与 简单 “监管 系统 代理 ”构件 的 
供给 端口 相连 ， 两 个 端口 由 于 提供 相同 的 接口 因而 均 命名 为 PAGV System。 与 这 两 个 端口 相 
关 的 连接 器 实际 上 是 一 个 委托 连接 器 ， 这 意味 着 “AGYV 系统 ”提供 的 外 部 端口 会 转发 每 个 接 
收 到 的 消息 到 “监管 系统 代理 ”提供 的 内 部 端口 。 “显示 代理 ”构件 的 请 求 端口 也 通过 委托 连 
feat SRA “АСУ 系统 ”构件 的 请 求 端口 相连 。 

执行 车 辆 状态 机 的 “车 辆 控制 ”构件 具有 一 个 供给 端口 ， 该 端口 提供 用 于 接收 来 自 “ 监 
管 系统 代理 ”和 “到 达 传 感 器 构件 ”的 所 有 消息 的 接口 。 这 样 ,“ 车 辆 控制 ”以 先进 先 出 
( FIFO ) 的 方式 接收 所 有 到 达 的 消息 。“ 车 辆 状态 ”也 拥有 一 个 供给 端口 和 一 个 供给 接口 ， 由 
于 “车 辆 状态 ”对 象 是 被 动 的 ， 它 提供 了 被 “车 辆 控制 ”构件 和 “车 辆 计时 器 ”调用 的 操作 。 
“车 辆 控制 ”也 具有 两 个 用 来 与 “机 械 臂 构件 ”和 “发 动机 构件 ”通信 的 请 求 端口 。 
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图 24-15 基于 构件 的 “自动 引导 车 辆 系统 ”软件 体系 结构 


在 图 24-14 中 ， 由 于 两 个 消息 生产 者 构件 ( “监管 系统 代理 ”和 “到 达 传 感 器 构件 ”) 发 
送 消息 给 “车 辆 控制 ”构件 ， 因 此 每 个 生产 者 构件 被 设计 成 具有 一 个 输出 端口 〈 称 为 请 求 
端口 ) 和 一 个 输入 端口 ( 称 为 供给 端口 )， 两 个 端口 通过 连接 器 相连 ， 如 图 24-15 所 示 。 生 
产 者 构件 中 的 请 求 端口 名 称 为 RAGVCtrl ; 根据 COMET 的 惯例 ， 端 口 名 称 中 的 第 一 个 字母 
R 用 来 强调 该 构件 具有 一 个 请 求 端口 (required port )。“ 车 辆 控制 ”构件 的 供给 端口 名 称 为 
PAGVCtrl ; 其 第 一 个 字母 P 用 于 强调 该 构件 具有 一 个 供给 端口 (provided port )。 连 接 器 用 来 
建立 两 个 生产 者 构件 的 请 求 端口 和 控制 构件 的 供给 端口 。 
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2477 ”构件 接口 设计 


每 个 构件 端口 都 是 按照 其 请 求 接口 和 /或 供给 接口 进行 定义 的 。 有 些 消息 生产 者 构件 
(特别 是 输入 构件 ) 不 提供 软件 接口 ， 这 是 由 于 此 类 构件 直接 从 外 部 硬件 输入 设备 接收 输入 ， 
但 是 这 些 构件 需要 通过 控制 构件 提供 的 接口 向 控制 构件 发 送 消息 。 图 24-16 给 出 了 输入 构件 
“到 达 传 感 器 构件 ”( Arrival Sensor Component ) 的 端口 和 请 求 接 口 。 此 输入 构件 以 及 “监管 
系统 代理 ”构件 具有 相同 的 请 求 接 口 IAGVControl， 该 接口 由 “车 辆 控制 ”构件 提供 。 

“车 辆 控制 ”构件 具有 三 个 请 求 端口 ， 通 过 这 些 端 口 “ 车 辆 控制 ”构件 可 以 发 送 消 息 给 
图 24-14 中 所 示 的 两 个 输出 构件 (“机械 辟 构件 ”和 “发 动机 构件 ”) 的 供给 端口 ， 而 且 “ 车 
辆 控制 ”构件 通过 “车 辆 状态 ”数据 抽象 对 象 的 供给 端口 调用 其 操作 。 

输出 构件 因为 直接 输出 至 外 部 硬件 输出 设备 而 无 需 软 件 接口 ， 但 是 需要 提供 接口 以 接收 
来 自 于 控制 构件 的 消息 。 图 24-16 给 出 了 “AGYV 系统 ”中 两 个 输出 构件 的 端口 和 供给 接口 。 
图 24-17 给 出 了 这 两 个 输出 构件 接口 的 规约 ， 规 约 中 说 明了 它们 提供 的 操作 。“ 机 械 臂 构件 ” 
和 “发 动机 构件 ”输出 构件 均 具 有 一 个 供给 端口 : 

e“ 机 械 臂 构件 ”的 PArm 端口 ， 提 供 接 口 LArm; 

e“ 发 动机 构件 ”的 PMotor 端口 ， 提 供 接 口 IMotor。 

“显示 代理 ”构件 具有 一 个 称 为 PDisplay 的 供给 端口 ， 该 端口 继而 提供 一 个 称 为 IDisplay 
的 接口 ， 如 图 24-16 所 示 。 图 24-17 给 出 了 接口 的 规约 。 

有 些 构件 〈 例如 控制 构件 ) 需要 为 消息 生产 者 构件 提供 使 用 接口 并 需要 输出 构件 所 提供 
的 接口 。“ 车 辆 控制 ”构件 具有 多 个 端口 〈 一 个 供给 端口 和 三 个 请 求 端口 )， 如 图 24-16 所 示 。 
每 个 请 求 端口 用 于 与 不 同 消费 者 构件 之 间 的 交互 ， 这 些 端口 的 命名 使 用 前 级 R， 例 如 RArm。 
而 供给 端口 称 为 PAGVControl， 提 供 接 口 [AGVControl 给 消息 生产 者 构件 使 用 。 

“车 辆 控制 ”构件 СМ 24-14 和 图 24-15 ) 执行 АСУ RER, 并 有 旦 从 两 个 生产 者 构件 
接收 异步 控制 请 求 消息 。 供 给 接口 [AGVControl 在 图 24-17 中 说 明 ， 接 口 很 简单 ， 只 包含 一 
个 操作 processControlRequest， 该 操作 具有 一 个 输入 参数 controlRequest， 参 数 中 包含 单个 消 
息 的 名 称 和 内 容 。 考 虑 到 系统 的 演化 ， 在 接口 中 为 每 个 控制 请 求 分 别 设计 操作 会 使 接口 过 于 
复杂 ， 因 为 系统 演化 通常 需要 操作 的 增加 或 删除 而 不 仅仅 是 参数 的 变更 。 
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24-17 “自动 引导 车 辆 系统 ”的 构件 接口 规约 


周期 性 计时 器 构件 的 端口 和 接口 在 图 24-16 和 图 24-17 中 给 出 。 “车 辆 计时 器 ”( Vehicle 
Timer) 具有 两 个 请 求 端口 以 及 两 个 请 求 接 口 。 第 一 个 请 求 接口 是 IAGVStatus， 该 接口 允许 
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从 “车 辆 状态 ”数据 抽象 对 象 读 取 АСУ 状态 信息 。 第 二 个 请 求 接口 是 IDisplay， 该 接口 允许 
“车 辆 计时 器 ”发 送 АСУ 状态 消息 给 “显示 代理 ”构件 。 

被 动 数据 抽象 对 象 “ 车 辆 状态 ”的 端口 和 接口 在 图 24-16 和 图 24-17 中 给 出 。“ 车 辆 状 
态 ”( Vehicle Status ) 对 象 提供 一 个 具有 三 个 操作 的 接口 。 其 中 “更 新 ”(update ) 操作 保存 
下 一 个 АСУ 目标 站 点 以 及 在 目标 站 点 需要 执行 的 命令 ( 装 货 或 印 货 ) “ЖЕ” (check) 操 
作 接 收 当前 站 点 编号 并 返回 该 站 点 是 否 为 目标 站 点 ， 如 果 是 则 进一步 返回 站 点 的 命令 是 装 货 
AMR. “Ж” (read) 操作 返回 位 置 、 目 标 站 点 以 及 装 货 /和 件 货 命令 。 图 24-18 中 显示 了 
被 动 数 据 抽 象 对 象 “车 辆 状态 ”的 各 个 属性 。 图 中 也 给 出 了 为 “车 辆 状态 机 ”( Vehicle State 
Machine ) 设计 的 状态 机 类 ， 该 类 被 封装 在 “车 辆 控制 ”构件 中 。 


«data abstraction» 
VehicleStatus 
- AGVid : Integer = 0 
- destination : Integer = 0 


- location : Integer = 0 
- loadUnload : Boolean = unload 


+ update (in destination, in loadUnload) 
+ check (in currentStation#, out response) 


+ read (out AGVid, out location 
out destination,out loadUnioad) 
+ clear () 


«state machine» 
VehicleStateMachine 
| 


+ processEvent (in event, out action) 
493 + currentState () : State 





494 图 24-18 “车 辆 状态 ”数据 抽象 类 和 “车 辆 状态 机 ”类 


| 附录 A 


Software Modeling & Design: UML, Use Cases, Patterns, & Software Architectures 


软件 体系 结构 模式 分 类 





从 模式 的 预期 用 户 的 角度 而 言 ， 一 个 描述 模式 的 模板 通常 含有 以 下 几 个 项 目 : 
模式 名 。 
别名 。 这 个 模式 的 其 他 名 字 。 
上 下 文 。 引 出 这 个 问题 的 情景 。 
问题 。 问 题 的 简单 描述 。 
о 解决 方案 的 总 结 。 解 决 方案 的 简要 描述 。 
° 解决 方案 的 优点 。 用 来 确定 这 个 解决 方案 对 于 你 的 设计 问题 是 否 是 正确 的 。 
© 解决 方案 的 缺点 。 用 来 确定 这 个 解决 方案 对 于 你 的 设计 问题 是 否 是 错误 的 。 
ө 适用 性 。 可 以 使 用 这 个 模式 的 情景 。 
е 相关 的 模式 。 考 虑 你 的 解决 方案 的 其 他 模式 。 
• 参考 。 可 以 找到 关于 这 个 模式 更 多 信息 的 地 方 。 
体系 结构 结构 模式 、 体 系 结构 通信 模式 以 及 体系 结构 事务 模式 分 别 在 АЛ 节 、A.2 节 以 
及 A.3 节 中 按照 这 个 模板 记录 。 这 些 模式 总 结 在 表 А-1 ~ 表 A-3 中 。 


表 A-1 软件 体系 结构 结构 模式 


软件 体系 结构 结构 模式 模式 描述 参考 章节 
代理 者 模式 A.1.1 节 第 16 章 ，16.2 节 
集中 式 控制 模式 А.1.2 і 5 18 2, 18.3.1 77 
分 布 式 控制 模式 A.1.3 节 第 18 章 ，18.3.2 节 
层次 化 控制 模式 A.1.4 节 第 18 章 ，18.3.3 节 
抽象 分 层 模式 A.1.5 节 第 12 #1, 1231 
多 客户 端 / 多 服务 模式 A.1.6 节 第 15 章 ，15.2.2 节 
多 客户 端 / 单 服务 模式 A.1.7 节 第 15 章 ，15.2.1 节 
多 层 客 户 端 /服务 模式 A.1.8 节 第 15 章 ，15.2.3 节 


ЖА-2 软件 体系 结构 通信 模式 


软件 体系 结构 通信 模式 模式 描述 参考 章节 

异步 消息 通信 模式 А21 节 $128, 12.33% 
带 回调 的 异步 消息 通信 模式 A.2.2 节 第 15 章 ，15.3.2 节 
双向 异步 消息 通信 模式 A.2.3 节 第 12 章 ，12.3.3 节 
广播 模式 A.2.4 节 第 17 章 ，17.6.1 节 
代理 者 转发 模式 A.2.5 节 第 16 章 ，16.2.2 节 
代理 者 句柄 模式 A.2.6 节 第 16 章 ，16.2.3 节 
调用 /返回 模式 A.2.7 节 第 12 章 ，12.3.2 节 


协商 模式 A.2.8 节 第 16 章 ，16.5 节 
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(Ж) 

软件 体系 结构 通信 模式 模式 描述 参考 章节 

服务 发 现 模式 A.2.9 节 第 16 章 ，16.2.4 节 
服务 注册 模式 A.2.10 4 第 16%, 16.2.14 
订阅 /通知 模式 А211% #1712, 17.6.2 # 
带 回复 的 同步 消息 通信 模式 A2.12 节 ts 
不 带 回 复 的 同步 消息 通信 模式 A.2.13 节 第 18 章 ，18.8.3 节 

表 A-3 软件 体系 结构 事务 模式 

软件 体系 结构 事务 模式 模式 描述 参考 章节 
复合 事务 模式 A.3.1 节 第 16 章 ，16.4.2 节 
长 事务 模式 А.3.2 节 第 16 章 ，16.4.3 节 
两 阶段 提交 协议 模式 A.3.3 节 第 16 章 ，16.4.1 节 


A.1 软件 体系 结构 的 结构 模式 


本 节 按 照 字母 顺序 并 使 用 标准 模板 描述 了 体系 结构 的 结构 模式 ， 这 些 模 式 针 对 体系 结构 
的 静态 结构 。 


A.1.1 ”代理 者 模式 


模式 名 代理 者 

别名 对 象 代理 者 、 对 象 请 求 代理 者 

上 下 文 软件 体系 结构 设计 ， 分 布 式 系统 

问题 在 分 布 式 应 用 中 ， 多 个 客户 端 与 多 个 服务 通信 。 客 户 端 不 知道 服 
务 的 位 置 。 

解决 方案 的 总 结 服务 向 代理 者 注册 。 客 户 端 发 送 服务 请 求 给 代理 者 。 代 理 者 扮演 
客户 端 和 服务 的 中 介 。 


解决 方案 的 优点 位 置 透明 性 :服务 可 以 方便 地 重 定 位 。 客 户 端 不 需要 知道 服务 的 位 置 。 
解决 方案 的 缺点 由 于 在 消息 通信 中 涉及 了 代理 者 而 需要 额外 的 开销 。 如 果 代 理 者 
有 高 负载 ， 那 么 代理 者 可 能 会 成 为 瓶颈 。 客 户 端 可 能 保留 而 不 是 
丢弃 过 时 的 服务 句柄 。 
分 布 式 环境 : 有 多 个 服务 的 客户 端 /服务 和 分 布 式 应 用 
代理 者 转发 ， 代 理 者 句柄 
第 16 章 ，16.2 节 
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定位 服务 у 


т я 











图 A-1 代理 者 模式 


А.1.2 ”集中 式 控制 模式 


模式 名 集中 式 控制 

别名 集中 式 控制 器 ， 系 统 控制 器 

上 下 文 需要 整体 控制 的 集中 式 应 用 

问题 多 个 动作 和 活动 是 状态 相关 的 ， 并 且 需 要 控制 和 顺序 化 。 

解决 方案 的 总 结 有 一 个 控制 构件 ， 它 概念 上 执行 一 个 状态 机 并 且 提 供 系统 或 者 子 
系统 的 整体 控制 和 顺序 化 。 


解决 方案 的 优点 在 一 个 构件 内 封装 了 所 有 状态 相关 的 控制 。 

解决 方案 的 缺点 云 会 导致 过 度 集 中 式 的 控制 ， 在 这 种 情况 下 应 该 考虑 分 布 式 
控制 。 

适用 性 实时 控制 系统 状态 相关 的 应 用 

相关 的 模式 分 布 式 控制 ， 层 次 化 控制 

参考 第 18 章 ，18.3.1 节 
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«input» «input» 














«component» «component» «input» х 
: DoorComponent : WeightComponent | «component» 
: KeypadComponent 





sendControiRequest 


(doorEvent) | sendControlRequest > 


(weightEvent) 


sendControlRequest(keypadEvent) 








«control» 
«component» 
: MicrowaveControl 


displayPrompt(promptid) 
displayTime(time) 

startCooking(level) Sk 

stopCooking() 



















«output» 
«output» «component» 
«component» : MicrowaveDisplay 
HeatingElementComponen 


498 图 A-2 集中 式 控制 模式 : 微波 炉 控制 系统 的 例子 


A.1.3 ”分 布 式 控 制 模式 


模式 名 分 布 式 控制 

别名 分 布 式 控制 器 

上 下 文 具有 实时 控制 需求 的 分 布 式 应 用 

问题 在 有 多 个 位 置 的 分 布 式 应 用 中 需要 在 多 个 位 置 进行 实时 的 本 地 化 


控制 。 
解决 方案 的 总 结 有 多 个 控制 构件 ， 使 得 每 个 构件 通过 概念 上 执行 一 个 状态 机 来 控 
制 一 个 系统 的 给 定 部 分 。 控 制 分 布 在 多 个 控制 构件 中 ,没有 一 个 


构件 有 全 局 的 控制 。 

解决 方案 的 优点 克服 了 过 度 集 中 式 控 制 的 可 能 问题 。 

解决 方案 的 缺点 没有 一 个 整体 的 协调 者 。 如 果 需 要 它 ， 可 以 考虑 使 用 层次 化 控制 
模式 。 

适用 性 分 布 式 实时 控制 的 、 分 布 式 状态 相关 的 应 用 

相关 的 模式 层次 化 控制 ， 集 中 式 控 制 

参考 第 18 章 ，18.3.2 ў 

























«control» 
«component» 
: Distributed 
Controller 


«control» 
«component» 
: Distributed 
Controller 


«control» 
«component» 
: Distributed 
Controller 















=— < 一 
event event 







actuator 


sensor Output 


Input 





actuator sensor 


actuator Sensor 
\ Output Input 


\ Output Input А 



















































«input» сори» «input» зори» «input» «output» 
«component» component» «component» component» «component» component» 
: SensorCmpt : ActuatorCmpt : SensorCmpt : ActuatorCmpt : SensorCmpt : ActuatorCmpt 
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АЛА ”层次 化 控制 模式 


模式 名 层次 化 控制 

别名 多 层 控 制 

上 下 文 具有 实时 控制 需求 的 分 布 式 应 用 

问题 在 有 多 个 位 置 的 分 布 式 应 用 中 需要 实时 的 本 地 化 控制 和 整体 的 控制 。 

解决 方案 的 总 结 有 多 个 控制 构件 ， 每 个 构件 通过 概念 上 执行 一 个 状态 机 来 控制 一 
个 系统 的 给 定 部 分 。 还 有 一 个 协调 者 构件 ， 它 提供 了 高 层 的 控 
H: 为 每 个 控制 构件 决定 下 一 个 任务 ， 并且 直接 把 这 个 信息 通知 


给 控制 构件 。 
解决 方案 的 优点 通过 提供 高 层 的 控制 和 协调 ， 克 服 了 分 布 式 控制 模式 的 可 能 问题 
解决 方案 的 缺点 当 负 载 高 并 且 是 一 个 单 点 缺陷 时 ,高 层 的 协调 者 可 能 会 成 为 
瓶颈 。 
适用 性 分 布 式 实时 控制 的 、 分 布 式 状态 相关 的 应 用 
相关 的 模式 分 布 式 控制 ， 集 中 式 控 制 
参考 第 18 章 ，18.3.3 节 





«coordinator» 








command 


response 






























«control» 
«component» 
: Distributed 
Controller 


«control» 
«component» 
: Distributed 
Controller 


«control» 

«component» 
; Distributed 
Controller 






actuator 


ы input Л 


«ошри» 
component» 
: ActuatorCmpt 


А.1.5 “抽象 分 层 模式 





«input» 
«component» 
: SensorCmpt 









component» 
; ActuatorCmpt 











图 А-4 层次 化 控制 模式 


模式 名 抽象 分 层 
别名 分 等 级 的 层次 、 抽 象 等 级 
上 下 文 软件 体系 结构 设计 


问题 一 个 鼓励 便于 扩展 和 收缩 设计 的 软件 体系 结构 。 
解决 方案 的 总 结 低层 的 构件 提供 服务 给 高 层 的 构件 。 构 件 可 能 只 能 使 用 由 低层 构 
件 提供 的 服务 。 
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解决 方案 的 优点 
解决 方案 的 缺点 
适用 性 
相关 的 模式 


参考 


促进 软件 设计 的 扩展 和 收缩 。 

如 果 需 要 遍历 太 多 层 ， 可 能 会 导致 低 效 率 。 

操作 系统 ， 通 信 协 议 ， 软件 产 品 线 

软件 内 核 可 以 是 抽象 分 层 体 系 结构 的 最 低层 。 这 个 模式 的 变 体 包 
括 灵 活 的 抽象 分 层 

第 12 章 ，12.3.1 #; Hoffman and Weiss 2001; Parnas 1979 





图 А-5 抽象 分 层 模式 : TCP/IP 的 例子 


A.1.6 ”多 客户 端 / 多 服务 模式 


模式 名 
别名 
上 下 文 


问题 
解决 方案 的 总 结 


多 客户 端 / 多 服务 

客户 端 / 服 务 、 客 户 端 /服务 器 

软件 体系 结构 设计 ， 分 布 式 系统 

在 分 布 式 应 用 中 多 个 客户 端 请 求 多 个 服务 的 服务 。 

客户 端 与 多 个 服务 通信 ， 通 常 是 串 行 的 ， 不 过 也 可 能 是 并 行 的 。 
每 个 服务 响应 客户 端的 请 求 。 每 个 服务 处 理 多 个 客户 端的 请 求 。 
一 个 服务 可 能 把 一 个 客户 端的 请 求 委托 给 另 一 个 服务 。 





解决 方案 的 优点 


解决 方案 的 缺点 


适用 性 
相关 的 模式 
参考 








EE РЕНЕА 
服务 1 
和 1 个 服务 器 结 点 } 






{1 个 客户 端 结 点 } 
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当 客户 端 需要 来 自 每 个 服务 的 不 同 信息 时 ， 这 是 一 个 客户 端 与 多 
个 服务 通信 的 好 方法 。 

如 果 在 任意 一 个 服务 器 有 高 负载 ， 那 么 客户 端 可 能 会 被 无 限 
阻塞 。 

分 布 式 处 理 : 有 多 个 服务 的 客户 端 / 服务 和 分 布 式 应 用 

多 客户 端 / 单 服务 ， 多 层 客 户 端 /服务 

第 15, 15.22 节 



















服务 2 
LIP HRS RE А) 





<< 局 域 网 >> 














客户 2 
{1 个 客户 端 结 点 } 


客户 3 
们 个 客户 端 结 点 } 


图 A-6 多 客户 端 /多 服务 模式 


A.1.7 ”多 客户 端 / 单 服务 模式 


模式 名 

别名 

上 下 文 

问题 

解决 方案 的 总 结 


解决 方案 的 优点 


解决 方案 的 缺点 


多 客户 端 / 单 服务 

客户 端 /服务 、 客 户 端 /服务 器 

软件 体系 结构 设计 ， 分 布 式 系统 

在 分 布 式 应 用 中 多 个 客户 端 需要 一 个 服务 的 服务 。 

客户 端 请 求 服务 。 服 务 响 应 客户 端的 请 求 并 且 不 发 起 请 求 。 服 务 
处 理 多 个 客户 端 请 求 。 

当 客 户 端 需要 服务 的 回复 时 ， 这 是 一 个 客户 端 与 服务 通信 的 好 方 
法 。 在 客户 端 / 服 务 器 应 用 中 ， 这 是 很 常见 的 通信 形式 。 

如 果 服 务 器 有 高 负载 ， 那 么 客户 端 可 能 会 被 无 限 阻 塞 。 
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分 布 式 处 理 : 客户 端 /服务 应 用 


多 客户 端 /多 服务 ， 多 层 客 户 端 /服务 
第 15 2, 15.2.1 节 





«external user» 
Operator 
«extemal output device» 
ReceiptPrinter 












«software system» 
BankingSystem 


















«client» 
«subsystem» 
ATMClient 


«service» 
«subsystem» 
BankingService 





«external input/output 1 
демсе» 
CardReader 
«extemal output device» 
CashDispenser 


А.1.8 多 层 客户 端 / 服务 模式 











«external user» 
ATMCustomer 


图 A-7 多 客户 端 / 单 服务 模式 :“ 银 行 系统 ”示例 


模式 名 多 层 客户 端 / 服务 

别名 客户 端 /服务 、 客 户 端 /服务 器 

上 下 文 软件 体系 结构 设计 ， 分 布 式 系统 

问题 在 分 布 式 应 用 中 有 多 层 服 务 。 

解决 方案 的 总 结 客户 端 请 求 服务 。 解 决 方案 有 多 层 服务 。 中 介 层 提供 了 客户 端 和 


服务 的 角色 。 可 以 有 多 个 中 介 层 。 

解决 方案 的 优点 如 果 处 理 一 个 个 体 客 户 端的 请 求 需 要 多 个 服务 并 且 一 个 服务 需要 
另 一 个 服务 的 辅助 ， 那 么 这 是 一 个 层次 化 服务 的 好 方法 。 

解决 方案 的 缺点 如 果 服 务 器 有 高 负载 ， 那 么 客户 端 可 能 会 被 无 限 阻塞 。 

适用 性 分 布 式 处 理 : 有 多 个 服务 的 客户 端 / 服务 和 分 布 式 应 用 
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相关 的 模式 多 客户 端 / 单 服 务 ， 多 客户 端 /多 服务 
参考 第 15 章 ，15.2.3 节 
AMT 客 户 |- 银行 服务 上-----------: 数据 库 服务 
图 A-8 多 层 的 客户 端 / 服 务 模式 :“ 银 行 系统 ”示例 504 


А.2 软件 体系 结构 通信 模式 


本 节 按 照 字 母 顺序 并 使 用 标准 模板 描述 了 体系 结构 通信 模式 ， 这 些 模 式 处 理 了 体系 结构 
的 分 布 式 构件 之 间 的 动态 通信 。 


А21 ”异步 消息 通信 模式 


模式 名 异步 消息 通信 

别名 松 耦 合 的 消息 通信 

上 下 文 并 发 或 者 分 布 式 系统 

问题 并 发 或 者 分 布 式 系统 有 需要 互相 通信 的 并 发 构件 。 生 产 者 不 需要 
等 待 消费 者 。 生 产 者 不 需要 回复 。 

解决 方案 的 总 结 在 生产 者 构件 和 消费 者 构件 之 间 使 用 消息 队列 。 生 产 者 发 送 消息 
给 消费 者 ， 然 后 继续 。 消 费 者 接收 消息 。 如 果 消 费 者 忙 ， 消 息 以 
先进 先 出 的 方式 排队 。 如 果 没 有 消息 ， 消 费 者 被 挂 起 。 如 果 消 费 
者 结 点 宕 了 ， 生 产 者 需要 超时 的 通知 。 

解决 方案 的 优点 消费 者 不 阻塞 生产 者 。 

解决 方案 的 缺点 如 果 生 产 者 生产 消息 的 速度 快 于 消费 者 处 理 消息 的 速度 ， 消 息 队 
列 最 终 会 溢出 。 

适用 性 集中 式 和 分 布 式 环境 : 实时 系统 、 客 户 端 /服务 和 分 布 式 应 用 

相关 的 模式 带 回调 的 异步 消息 通信 

参考 第 12 章 ，12.3.3 节 


1: sendAsynchronousMessage (in message) 
= 


aProducer aConsumer 





图 A-9 异步 消息 通信 模式 505 
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А22 ” 带 回 调 的 异步 消息 通信 模式 


模式 名 
别名 
上 下 文 
问题 


解决 方案 的 总 结 


解决 方案 的 优点 
解决 方案 的 缺点 
适用 性 


相关 的 模式 
参考 


aClient 


带 回调 的 异步 消息 通信 

带 回调 的 松 耦 合 通信 

并 发 或 者 分 布 式 系统 

并 发 或 者 分 布 式 应 用 中 需要 互相 通信 的 并 发 构件 。 客 户 端 不 需要 
等 待 服务 ， 但 是 需要 收 到 一 个 回复 。 

客户 端 和 服务 之 间 使 用 同步 通信 。 客 户 端 发 送 请 求 给 服务 ， 包 
括 客户 端 操 作 (回调 ) 句柄 。 客 户 端 不 需要 等 待 回 复 。 在 服务 
处 理 客 户 端 请 求 之 后 ， 它 使 用 句柄 来 远程 地 调用 客户 端 操作 
(回调 )。 

当 客 户 端 需要 一 个 回复 但 是 能 够 继续 执行 并 且 在 稍 后 接收 回复 
时 ， 这 是 一 个 客户 端 与 服务 通信 的 好 方法 。 

仅仅 适用 于 客户 端 在 接收 第 一 个 回复 之 前 不 需要 发 送 多 个 请 求 的 
情况 。 

分 布 式 环境 : 有 多 个 服务 的 客户 端 /服务 和 分 布 式 应 用 

考虑 双向 异步 消息 通信 作为 候选 模式 

第 15 章 ，15.3.2 节 





1: sendAsynchronousMessage 
(in message, in callbackHandle) 


= 





aService 
<—___ 


2: sendCallbackResponse (in response) 


图 A-10 带 回调 的 异步 消息 通信 


A.2.3 ”双向 异步 消息 通信 模式 


解决 方案 的 总 结 


双向 异步 消息 通信 

双向 松 耦 合 的 消息 通信 

并 发 或 者 分 布 式 系统 

并 发 或 者 分 布 式 应 用 有 需要 互相 通信 的 并 发 构件 。 生 产 者 不 需要 


等 待 消费 者 ， 尽 管 稍 后 它 需 要 接收 回复 。 生 产 者 在 接收 第 一 个 回 
复 之 前 能 够 发 送 多 个 请 求 。 

在 生产 者 构件 和 消费 者 构件 之 间 使 用 两 个 消息 队列 : 一 个 给 从 生 
产 者 到 消费 者 的 消息 ， 一 个 给 从 消费 者 到 生产 者 的 消息 。 生 产 者 
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解决 方案 的 优点 


解决 方案 的 缺点 


aProducer 


A.2.4 “广播 模式 


模式 名 
别名 
上 下 文 
问题 


解决 方案 的 总 结 


解决 方案 的 优点 
解决 方案 的 缺点 


适用 性 
相关 的 模式 
参考 


在 P 一 C 队列 上 发 送 消息 给 消费 者 ， 然 后 继续 。 消 费 者 接收 
消息 。 如 果 消 费 者 忙 ， 消 息 排队 。 消 费 者 在 C 一 P 队列 上 发 
送 回复 。 

生产 者 不 会 被 消费 者 阻塞 。 当 生产 者 需要 回复 的 时 候 ， 它 稍 后 接 
收回 复 。 

如 果 生 产 者 生产 消息 的 速度 快 于 消费 者 处 理 消 息 的 速度 ， 消 息 队 
列 P 一 C 最终 会 溢出 。 如 果 生 产 者 没有 尽 够 快 地 进行 回复 ， 回 复 
队列 C 一 了 将 会 溢出 。 

集中 式 和 分 布 式 环境 : 实时 系统 、 客 户 端 /服务 器 和 分 布 式 
应 用 

带 回 调 的 异步 消息 通信 

第 12 章 ，12.3.3 ўї 





1: sendAsynchronousMessage (in message) 
—> 





aConsumer 
一 一 一 一 一 


2: sendAsynchronousResponse (in response) 


图 A-11 双向 异步 消息 通信 模式 


广播 

广播 通信 

分 布 式 系统 

分 布 式 应 用 有 多 个 客户 端 和 服务 。 有 时 一 个 服务 需要 发 送 同一 个 
消息 给 多 个 客户 端 。 

粗野 的 群 组 通信 形式 ， 其 中 服务 发 送 消息 给 所 有 的 客户 端 而 不 管 
客户 端 是 否 想 要 这 个 消息 。 客 户 端 决定 它 想 要 处 理 这 个 消息 还 是 
丢弃 这 个 消息 。 

群 组 通信 的 简单 形式 。 

由 于 客户 端 可 能 不 想 要 这 个 消息 ， 所 以 给 客户 端 带 来 了 额外 的 
负载 。 

分 布 式 环境 : 有 多 个 服务 器 的 客户 端 / 服务 器 和 分 布 式 应 用 

类 似 于 “订阅 /通知 "， 除 了 它 不 是 选择 性 的 

第 17 章 ，17.6.1 # 
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«user interaction» 
«component» 
firstOperatorinteraction 





> 
B2a: alarmBroadcast 
«user interaction» 


«component» 
secondOperatorinteraction 






一 
B2b: alarmBroadcast 





«service» 
; AlarmHandlingService 


B1: alarm | 





Зы 


В2с: alarmBroadcast 















«input» 
«component» 
: EventMonitor 


«user interaction» 
«component» 
thirdOperatorinteraction 






图 A-12 广播 模式 : 警报 广播 的 例子 


А.2.5 ”代理 者 转发 模式 


模式 名 代理 者 转发 

别名 白 页 代理 者 转发 、 带 转发 设计 的 代理 者 

ETX 分 布 式 系统 

问题 分 布 式 应 用 中 多 个 客户 端 与 多 个 服务 通信 。 客 户 端 不 知道 服务 的 位 置 。 

解决 方案 的 总 结 服务 向 代理 者 注册 。 客 户 端 发 送 服 务 请 求 给 代理 者 。 代 理 者 转发 
请 求 给 服务 。 服 务 处 理 请 求 ， 并 发 送 回复 给 代理 者 。 代 理 者 转发 
回复 给 客户 端 。 


解决 方案 的 优点 位 置 透明 性 :服务 可 以 方便 地 重 定位 。 客 户 端 不 需要 知道 服务 的 位 置 。 

解决 方案 的 缺点 由 于 在 所 有 的 消息 通信 中 都 涉及 代理 者 而 带 来 额外 的 开销 。 如 果 
代理 者 有 高 负载 ， 代 理 者 就 成 为 了 瓶颈 。 

适用 性 分 布 式 环境 : 有 多 个 服务 器 的 客户 端 /服务 器 和 分 布 式 应 用 

相关 的 模式 类 似 于 代理 者 句柄 ; 更 安全 ,但 是 性 能 不 太 好 

参考 第 16 章 ，16.2.2 节 








一 个 服务 请 求 者 


图 A-13 ”代理 者 转发 模式 


А26 ”代理 者 句柄 模式 


模式 名 

别名 

EFX 

问题 

解决 方案 的 总 结 


解决 方案 的 优点 
解决 方案 的 缺点 


适用 性 
相关 的 模式 
参考 


B1: 服 务 请 求 





А27 ”调用 /返回 模式 


模式 名 
别名 
EFX 


问题 
解决 方案 的 总 结 


一 个 服务 请 求 者 
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代理 者 句柄 

白 页 代理 者 句柄 ， 带 句柄 驱动 设计 的 代理 者 

分 布 式 系统 

分 布 式 应 用 中 多 个 客户 端 与 多 个 服务 通信 。 客 户 端 不 知道 服务 的 位 置 。 
服务 向 代理 者 注册 。 客 户 端 发 送 服务 请 求 给 代理 者 。 代 理 者 返回 
服务 句柄 给 客户 端 。 客 户 端 使 用 服务 句柄 向 服务 发 出 请 求 。 服 务 
处 理 请 求 并 且 直 接 发 送 回复 给 客户 端 。 客 户 端 能 够 向 服务 发 送 多 


个 请 求 而 不 需要 涉及 代理 者 。 

位 置 透明 性 :服务 能 够 方便 地 重 定位 。 客 户 端 不 需要 知道 服务 的 位 置 。 
由 于 在 初始 消息 通信 中 涉及 代理 者 而 带 来 了 额外 的 开销 。 如 果 代 
理 者 有 高 负载 ， 代 理 者 就 成 为 了 瓶颈 。 客 户 端 可 能 会 持 有 而 不 是 
丢弃 一 个 过 时 的 服务 句柄 。 

分 布 式 环境 : 有 多 个 服务 器 的 客户 端 /服务 器 以 及 分 布 式 应 用 
类 似 于 代理 者 转发 ， 但 是 有 更 好 的 性 能 

第 16 章 ，16.2.3 节 













Ра 
2 B2: 服 务 句 柄 


B3: 带 句柄 的 服务 请 求 
— 





<= ав оно а 
B4: 服 务 回 复 


图 A-14 代理 者 句柄 模式 


调用 /返回 模式 

操作 调用 、 方 法 调用 

面向 对 象 的 程序 和 系统 

一 个 对 象 需要 调用 一 个 不 同 的 对 象 的 一 个 操作 ( 也 被 认为 是 方法 )。 
在 一 个 调用 对 象 中 的 一 个 调用 操作 调用 了 一 个 被 调用 对 象 中 的 一 
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解决 方案 的 优点 
解决 方案 的 缺点 


适用 性 


相关 的 模式 
参考 


А28 ”协商 模式 


模式 名 

别名 

上 下 文 

问题 

解决 方案 的 总 结 


解决 方案 的 优点 
解决 方案 的 缺点 
适用 性 





个 被 调用 操作 。 在 操作 调用 的 时 候 ， 控 制 以 及 任何 输入 参数 从 调 
用 操作 被 转移 到 被 调用 操作 。 当 被 调用 操作 完成 执行 时 ， 它 把 控 
制 和 任何 输出 参数 返回 给 调用 操作 。 

这 个 模式 是 在 串 行 设计 中 对 象 之 间 唯 一 可 能 的 通信 形式 。 

如 果 这 个 模式 的 通信 不 合适 ,那么 在 大 多 数 情况 下 会 需要 一 个 并 


发 的 或 者 分 布 式 的 解决 方案 。 

串 行 的 面向 对 象 的 体系 结构 、 程 序 和 系统 。 一 个 带 内 部 对 象 的 、 
被 设计 为 串 行 子 系统 的 服务 会 使 用 这 个 模式 

使 用 消息 传递 而 不 是 操作 调用 的 软件 体系 结构 通信 模式 

第 12 章 ，12.3.2 节 





: Calling Object 






invokeOperation(in inputParameter, 
out outputParameter) 


: Called Object 


图 A-15 调用 /返回 模式 


协商 

基于 主体 的 协商 、 多 主体 协商 

分 布 式 多 主体 系统 ; 面向 服务 的 体系 结构 

客户 端 需要 与 多 个 服务 协商 来 找到 最 好 的 可 用 服务 。 

客户 端 主体 代表 客户 端 向 代表 服务 的 服务 主体 做 出 提议 。 服 务 主 
体 尝 试 着 满足 客户 端的 提议 ， 这 通常 涉及 与 其 他 服务 的 通信 。 确 
定 了 可 用 的 选项 之 后 ， 服 务 主 体会 提供 一 个 或 者 多 个 最 接近 于 原 


来 客户 端 主体 提议 的 选项 。 客 户 端 主体 可 以 请 求 其 中 的 一 个 选项 、 
提出 其 他 选项 或 者 拒绝 这 个 提议 。 如 果 服 务 主体 能 够 满足 客户 端 
主体 的 请 求 ， 客 户 端 主体 接受 这 个 请 求 ; 否则 ， 它 拒绝 这 个 请 求 。 
提供 协商 服务 来 补充 其 他 服务 。 

协商 可 能 是 宛 长 的 而 且 没 有 结果 。 

分 布 式 环境 : 有 多 个 服务 的 客户 端 /服务 以 及 分 布 式 应 用 ， 面 向 
服务 的 体系 结构 
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经 常 与 代理 者 模式 (代理 者 转发 、 代 理 者 句柄 、 服 务 发 现 ) 一 起 使 用 


Ж 16, 16.5 ў 






unifiedAirlines 
ReservationService 


i a 1: response 


2a: flightQuery 





5: reserve 
1: propose (tripToLondon, 
depart 14 Oct., 
return 21 Oct., <$700) 7277 6: reject 
4: request (UA $750) 
8: request (BA $775) 









aClientAgent 


7: reject, 
11: accept 


A.2.9 ”服务 发 现 模式 


模式 名 
别名 
上 下 文 
问题 


解决 方案 的 总 结 


解决 方案 的 优点 


解决 方案 的 缺点 


适用 性 
相关 的 模式 
参考 


一 一 之 


二 一 一 
3: offer (UA $750, BA $775), 













2b: query 9: reserve 


worldWide 
TravelAgent 


2c.1: а ie 


brittanicAirways 
ReservationService 

Virtual Atlantic 
ReservationService 





2b.1: response 10: confirm 






2c: query 





图 A-16 协商 模式 : 航班 预订 示例 


服务 发 现 

黄页 代理 者 、 代 理 者 交易 者 、 发 现 

分 布 式 系统 

分 布 式 应 用 中 多 个 客户 端 与 多 个 服务 通信 。 客 户 端 知道 请 求 的 服 
务 类 型 而 不 是 特定 的 服务 。 

使 用 代理 者 的 发 现 服务 。 服 务 向 代理 者 注册 。 客 户 端 发 送 发 现 服 
务 的 请 求 给 代理 者 。 代 理 者 返回 匹配 发 现 服务 请 求 的 所 有 服务 的 
名 字 。 客 户 端 选择 一 个 服务 并 且 使 用 代理 者 句柄 或 者 代理 者 转发 
模式 与 服务 通信 。 

位 置 透 明 性 : 服务 能 够 方便 地 重 定位 。 客 户 端 不 需要 知道 特定 的 
服务 而 只 需要 服务 类 型 。 

由 于 在 初始 消息 通信 中 涉及 代理 者 而 带 来 额外 的 开销 。 如 果 代 理 
者 有 高 负载 ， 代 理 者 可 能 会 成 为 瓶颈 。 

分 布 式 环境 : 有 多 个 服务 的 客户 端 /服务 和 分 布 式 应 用 

其 他 代理 者 模式 (代理 者 转发 、 代 理 者 句柄 ) 

第 16 章 ，16.2.4 节 
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1: 查 询 服 务 


3: 选 择 一 个 服务 Z я 
д АА 


图 A-17 服务 发 现 模 式 


A.2.10 ”服务 注册 模式 


模式 名 服务 注册 

别名 代理 者 注册 

上 下 文 软件 体系 结构 设计 、 分 布 式 系统 

问题 分 布 式 应 用 中 多 个 客户 端 与 多 个 服务 通信 。 客 户 端 不 知道 服务 的 位 置 。 

解决 方案 的 总 结 服务 向 代理 者 注册 服务 信息 ， 包 括 服务 名 称 、 服 务 描述 以 及 位 
置 。 客 户 端 发 送 服 务 请 求 给 代理 者 。 代 理 者 扮演 客户 端 和 服务 之 
间 的 中 介 者 。 

解决 方案 的 优点 位 置 透 明 性 : 服务 能 够 方便 地 重 定 位 。 客 户 端 不 需要 知道 服务 的 
位 置 。 

解决 方案 的 缺点 由 于 在 消息 通信 中 涉及 代理 者 而 带 来 额外 的 开销 。 如 果 代 理 者 有 
高 负载 ， 代 理 者 可 能 会 成 为 瓶颈 。 

适用 性 分 布 式 环境 : 有 多 个 服务 的 客户 端 /服务 和 分 布 式 应 用 

相关 的 模式 代理 者 、 代 理 者 转发 、 代 理 者 句柄 、 服 务 发 现 

参考 第 16 章 ，16.2.1 节 





图 A-18 服务 注册 模式 
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А.2.11 ”订阅 /通知 模式 


模式 名 

别名 

上 下 文 

问题 

解决 方案 的 总 结 


解决 方案 的 优点 
解决 方案 的 缺点 
适用 性 
相关 的 模式 
参考 













«service» 







N1: alarm | 


«input» 
«component» 
: EventMonitor 


: AlarmHandlingService 








订阅 /通知 

广播 

分 布 式 系统 

有 多 个 客户 端 和 服务 的 分 布 式 应 用 。 客 户 端 想 要 接收 给 定 类 型 的 消息 。 
群 组 通信 的 选择 性 形式 。 客 户 端 订阅 接收 给 定 类 型 的 消息 。 当 服 
务 接收 这 个 类 型 的 消息 时 ， 它 通知 所 有 订阅 它 的 客户 端 。 

群 组 通信 的 选择 性 形式 。 广 泛 应 用 于 互联 网 和 万 维 网 应 用 。 

如 果 客 户 端 订阅 了 太 多 的 服务 ， 它 可 能 会 出 乎 意料 地 接收 大 量 的 消息 。 
分 布 式 环境 : 有 多 个 服务 的 客户 端 /服务 和 分 布 式 应 用 

类 似 于 “广播 "， 除 了 它 更 具 选 择 性 

第 17 章 ，17.6.2 节 



















«user interaction» 
«component» 


$1: subscribe firstOperatorinteraction 


а 


N2a: alarmNotify 


«user interaction» 
«component» 
secondOperatorinteraction 





$2: subscribe 
<q——_—— 





一 一 > 
N2b: alarmNotify 


3: subscribe 
а. 
в 


N2c: alarmNotify 














«user interaction» 
«component» 
thirdOperatorinteraction 





图 A-19 订阅 /通知 模式 : 警报 通知 示例 


А.2.12 “ 带 回 复 的 同步 消息 通信 模式 





带 回 复 的 同步 消息 通信 
带 回复 的 紧 耦 合 的 消息 通信 
并 发 或 者 分 布 式 系统 


并 发 或 者 分 布 式 系统 中 多 个 客户 端 与 一 个 服务 通信 。 客 户 端 需要 
等 待 服务 的 回复 。 


396 MRA KEKABHRADRE 


解决 方案 的 总 结 


解决 方案 的 优点 


解决 方案 的 缺点 
适用 性 
相关 的 模式 
参考 


~ 


在 客户 端 和 服务 之 间 使 用 同步 通信 。 客 户 端 发 送 消息 给 服务 并 且 
等 待 回复 。 由 于 有 许多 客户 端 ， 所 以 在 服务 端 使 用 消息 队列 。 服 
务 以 先进 先 出 的 方式 处 理 消 息 。 服 务 发 送 回 复 给 客户 端 。 当 客户 
端 从 服务 接收 到 消息 时 ， 客 户 端 被 激活 。 

当 客户 端 与 服务 通信 并 且 需 要 回复 时 ， 这 是 一 个 好 的 方法 。 这 个 
通信 形式 在 客户 端 / 服 务 器 应 用 中 很 常见 。 

如 果 服 务 器 有 高 负载 ， 客 户 端 可 能 会 被 无 限 阻 塞 。 

分 布 式 环境 : 有 多 个 服务 的 客户 端 / 服 务 和 分 布 式 应 用 


第 12 章 ，12.3.4 节 ; 第 15 章 ，15.3.1 节 





1: sendSynchronousMessagewithReply 
(in message, out response) 
— > 





带 回调 的 异步 消息 通信 
ЕЗ 








图 А-20 2157 НН ВОВЕ А, 


А.2.13 ”不 带 回复 的 同步 消息 通信 模式 


模式 名 
别名 
上 下 文 
问题 


解决 方案 的 总 结 


解决 方案 的 优点 


解决 方案 的 缺点 
适用 性 
相关 的 模式 
参考 


aProducer 





不 带 回复 的 同步 消息 通信 

不 带 回 复 的 紧 耦 合 的 消息 通信 

并 发 或 者 分 布 式 系统 

在 并 发 或 者 分 布 式 应 用 中 ， 并 发 构件 需要 互相 通信 。 生 产 者 需要 
等 待 消费 者 接受 消息 。 生 产 者 不 想 要 超过 消费 者 。 生 产 者 和 消费 
者 之 间 没 有 队列 。 

在 生产 者 和 消费 者 之 间 使 用 同步 通信 。 生 产 者 发 送 消息 给 消费 
者 ， 并 且 等 待 消费 者 接受 消息 。 消 费 者 接收 消息 。 如 果 没 有 消 
息 ， 消 费 者 就 被 挂 起 。 消 费 者 接受 消息 ， 从 而 有 释 放 了 生产 者 。 

当 生产 者 需要 消费 者 收 到 消息 的 确认 并 且 生 产 者 不 想 要 超过 消费 


者 时 ， 这 是 生产 者 与 消费 者 通信 的 好 方法 。 

如 果 消 费 者 忙于 做 其 他 事情 ， 生 产 者 可 能 会 被 无 限 阻塞 。 
分 布 式 环境 : 有 多 个 服务 的 客户 端 /服务 和 分 布 式 应 用 
考虑 把 带 回复 的 同步 消息 通信 作为 可 替换 模式 

第 18 章 ，18.8.3 节 


sendSynchronousMessagewithoutReply (in message) 
-一 -一 -一 > 


aConsumer 


图 A-21 不 带 回复 的 同步 消息 通信 模式 
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АЗ 件 体 系 结构 事务 模式 


本 节 按 照 字 母 顺序 并 使 用 标准 模板 描述 了 体系 结构 事务 模式 ， 这 些 模式 处 理 了 客户 端 / 
服务 器 体系 结构 中 的 事务 管理 。 


АЗЛ 复合 事务 模式 


模式 名 

别名 

上 下 文 分 布 式 系统 、 分 布 式 数据 库 

问题 客户 端 有 一 个 事务 需求 ， 它 可 以 被 分 解 为 更 小 的 、 独 立 的 扁平 
事务 。 

解决 方案 的 总 结 把 复合 事务 分 解 成 更 小 的 原子 事务 ， 每 个 原子 事务 可 以 被 独立 地 
执行 和 回 滚 。 


解决 方案 的 优点 为 可 以 分 解 为 两 个 或 者 多 个 原子 事务 的 事务 提供 了 有 效 的 支持 。 
如 果 只 有 其 中 的 一 个 事务 需要 回 滚 或 者 改变 ， 这 是 有 效 的 。 

解决 方案 的 缺点 为 了 确保 个 体 原子 事务 之 间 是 一 致 的 ， 这 需要 更 多 的 工作 。 如 果 
整个 复合 事务 需要 回 滚 或 者 改变 ， 这 需要 更 多 的 协调 。 

适用 性 事务 处 理应 用 、 分 布 式 数据 库 

相关 的 模式 两 阶段 提交 协议 、 长 事务 

参考 第 16 章 ，16.4.2 节 
















airline 
ReservationService 


1: flightReservation 


Z MA 2: flightConfirmation 





3: hotelReservation 
—> 












hotel 


worldWide ReservationService 


TravelAgent 








二 一 一 一 一 一 
4: hotelConfirmation 





5: carReservation 


6: пеш a 


vehicle 
RentalService 


图 A-22 复合 事务 模式 : 航班 /宾馆 /汽车 预订 示例 
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А.3.2 ”长 事务 模式 


模式 名 长 事务 

别名 

上 下 文 分 布 式 系统 、 分 布 式 数据 库 

问题 客户 端 有 一 个 长 事务 需求 ， 它 有 人 参与 其 中 ， 需 要 很 长 、 可 能 是 
无 限 的 时 间 来 执行 。 

解决 方案 的 总 结 把 一 个 长 事务 分 解 为 两 个 或 者 多 个 独立 的 原子 事务 ， 使 得 人 的 决 


策 发 生 在 连续 的 原子 事务 对 之 间 。 
解决 方案 的 优点 为 可 以 分 解 为 两 个 或 者 多 个 原子 事务 的 长 事务 提供 了 有 效 的 支持 。 
解决 方案 的 缺点 由 于 组 成 长 事务 的 连续 原子 事务 之 间 的 长 延迟 ， 情 况 可 能 发 生变 
化 ， 导 致 一 次 不 成 功 的 长 事务 。 
适用 性 事务 处 理应 用 、 分 布 式 数据 库 
相关 的 模式 两 阶段 提交 协议 、 复 合 事务 
参考 第 16 章 ，16.4.3 节 















unifiedAirlines 
Та: ReservationService 
flightQuery 





1a.1: 
























response 
2: reserve 777 3: 
reject 1b: : 
query 
rldWid = brittanicAi 
мо! іде = = rittanicAirways 
TravelAgent 16.1: 5: confirm ReservationService 
response 
N 1c: query 
12.1: K 


response 
virtualAtlantic 
ReservationService 


图 A-23 长 事务 模式 : 航班 预订 示例 


A.3.3 ”两 阶段 提交 协议 模式 


两 阶段 提交 协议 
原子 事务 


分 布 式 系统 、 分 布 式 数据 库 
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客户 端 产 生 事务 ， 并 且 把 它们 发 送 给 服务 来 处 理 。 一 个 事务 是 原 
子 的 ( 即 不 可 分 割 的 )。 它 有 两 个 或 者 多 个 操作 组 成 来 执行 一 个 
单一 的 逻辑 功能 ， 它 必须 全 部 完成 或 者 全 部 不 完成 。 

解决 方案 的 总 结 对 于 原子 事务 ， 服 务 需要 提交 或 者 中 止 事务 。 两 阶段 提交 协议 被 
用 于 在 分 布 式 应 用 中 同步 不 同 结 点 的 更 新 。 结 果 不 是 事务 被 提交 
(在 这 种 情况 下 所 有 的 更 新 都 成 功 ) 就 是 事务 被 中 止 (在 这 种 情 


况 下 所 有 的 更 新 都 失败 )。 
解决 方案 的 优点 为 原子 事务 提供 了 有 效 的 支持 。 
解决 方案 的 缺点 只 对 短 事务 有 效 ， 即 在 事务 的 两 个 阶段 之 间 没 有 长 延迟 。 
适用 性 事务 处 理应 用 、 分 布 式 数据 库 
相关 的 模式 复合 事务 、 长 事务 
参考 第 16 章 ，16.4.1 节 
la:prepareTo 


commit 
1a.3:readyTo ipee 











1b.3:readyTo 


commit 


secondService 


commit commit 





a) 两 阶段 提交 协议 的 第 一 个 阶段 
2b.3:commit 


:commitCoordinator 
T Completed 
2a.3:commit 2b:commit 





= 


Completed 





b) 两 阶段 提交 协议 的 第 二 个 阶段 
图 A-24 两 阶段 提交 协议 模式 


附录 B | 


Software Modeling & Design: UML, Use Cases, Patterns, & Software Architectures 





B.1 概述 


本 书 的 内 容 可 以 根据 可 用 的 时 间 以 及 学 生 的 知识 水 平 以 不 同 的 方式 进行 授课 。 这 个 附录 
描述 了 基于 本 书 的 可 能 的 学 术 性 课程 和 工业 性 课程 的 不 同安 排 。 

这 些 课程 的 前 提 条 件 是 修 读 过 关于 软件 工程 的 概论 性 课程 ， 涵 盖 软 件 生存 周期 以 及 生存 
周期 中 各 个 阶段 的 主要 活动 。 这 个 先导 性 课程 将 覆盖 关于 软件 工程 的 介绍 性 书籍 中 描述 的 内 
容 ， 例 如 ，Pressman ( Pressman 2009 ) 或 者 Sommerville ( Sommerville 2010 )。 

这 些 课 程 都 有 三 个 部 分 : 方法 的 描述 、 至 少 一 个 使 用 这 个 方法 的 案例 研究 以 及 一 个 给 学 
生 应 用 这 个 方法 到 现实 世界 问题 的 动手 设计 练习 。 


B.2 建议 的 学 术 性 课程 


以 下 的 学 术 性 课程 可 以 基于 本 书 所 涵盖 的 内 容 : 

1 ) 一 个 关于 软件 建 模 和 设计 的 高 年 级 本 科 生 或 研究 生 课 程 ， 包 含 针 对 每 种 体系 结构 类 别 
的 概述 。 

2) 一 个 前 述 课程 的 变 体 是 关注 其 中 某 种 类 型 的 体系 结构 ， 例 如 面向 服务 的 体系 结构 或 者 
基于 构件 的 软件 体系 结构 ， 包 含 一 个 详细 的 案例 研究 和 动手 设计 练习 。 

3) 一 个 设计 实验 的 课程 可 以 作为 软件 建 模 和 设计 课程 (课程 1 ) 的 后 续 课 程 ， 学 生 分 小 
组 工作 ， 开 发 针对 某 个 软件 体系 结构 的 真实 的 软件 问题 的 一 个 解决 方案 。 在 这 种 情况 下 ， 学 
生 也 可 以 完成 全 部 或 者 部 分 的 系统 实现 。 


В.З 建议 的 工业 课程 


以 下 的 工业 课程 可 以 基于 本 书 所 涵盖 的 内 容 : 

1) 关于 软件 建 模 和 设计 的 课程 。 首 先是 第 一 部 分 中 简单 的 概念 介绍 ， 然 后 课程 可 以 关注 
第 二 部 分 ， 根 据 课 程 的 长 度 ， 最 后 是 第 三 部 分 中 的 一 个 或 者 多 个 体系 结构 类 别 以 及 对 应 的 第 
四 部 分 中 的 案例 研究 。 例 如 ， 课 程 可 以 关注 面向 服务 的 体系 结构 ， 并 且 详 细 地 覆盖 “在 线 购 
物 系统 ”。 动 手 设计 练习 可 以 关注 选择 的 体系 结构 类 别 。 根 据 覆 盖 的 详细 等 级 ， 这 个 课程 可 以 
持续 2 天 到 5 天 的 任意 长 度 。 

2) 一 个 实际 的 动手 课程 ， 方 法 的 每 个 阶段 都 有 一 个 动手 的 设计 实验 。 假 设 是 一 个 内 部 课 
程 ， 设 计 实 验 可 以 是 一 个 公司 选择 的 问题 。 这 个 课程 将 关注 一 个 体系 结构 类 别 ， 例 如 基于 构 
件 的 软件 设计 。 一 个 选择 方案 是 分 阶段 的 课程 ， 每 个 阶段 的 方法 教学 与 这 个 阶段 的 实际 开发 
项 目 配合 进行 。 
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B.4 设计 练习 


这 个 讨论 适用 于 学 术 性 课程 和 工业 课程 。 

作为 课程 的 一 部 分 ， 学 生 应 该 单独 地 或 者 分 组 针对 一 个 或 者 多 个 现实 世界 问题 进行 工作 。 
是 否 要 解决 一 个 或 者 多 个 问题 取决 于 问题 的 大 小 以 及 课程 的 实践 。 然 而 ， 应 该 给 予 学 生 充 分 
的 时 间 来 解决 问题 ， 因 为 这 是 让 学 生 真正 理解 方法 的 最 好 途径 。 
可 以 使 用 以 下 软件 问题 : 
1) 微波 炉 系统 (实时 ) 
2) 超级 市 场 结账 系统 ( 客户 端 /服务 器 ) 
3) 工厂 自动 控制 系统 ( 基于 构件 的 软件 体系 结构 ) 
4) 库存 管理 系统 ( 面向 服务 的 系统 ) 
可 能 的 方法 如 下 所 示 : 
1 ) 在 整个 课程 中 关注 一 个 问题 ， 并 使 用 某 种 类 型 的 体系 结构 ， 例 如 面向 服务 的 体系 结 
这 个 方法 的 优势 是 学 生 能 够 深入 地 理解 方法 。 
2) 把 班级 分 成 小 组 。 每 个 小 组 使 用 不 同类 型 的 体系 结构 来 解决 同一 个 问题 。 在 课程 的 最 
后 安排 时 间 给 每 个 小 组 展示 他 们 的 解决 方案 。 在 课程 上 讨论 应 用 方法 时 遇 到 的 问题 以 及 是 如 
何 解决 这 些 问 题 的 。 

3 ) 一 个 设计 实验 的 课程 可 以 作为 软件 建 模 和 设计 课程 的 后 续 课 程 ， 学 生 分 小 组 工作 ， 开 
发 针对 某 类 体系 结构 的 真实 的 软件 体系 结构 的 一 个 解决 方案 。 在 这 种 情况 下 ， 学 生 也 可 以 完 
成 全 部 或 者 部 分 的 系统 实现 。 


构 


о 


№ 


А 


abstract class ( 抽象 类 ) 不 能 直接 实例 化 的 类 
(Booch, Rumbaugh, and Jacobson 2005 ). 比 
较 concrete class, 

abstract data type ( 抽象 数据 类 型 ) 通过 操纵 它 
的 操作 来 定义 并 因此 隐藏 了 其 表示 细节 的 一 种 
数据 类 型 。 

abstract interface specification ( 抽象 接口 规约 ) 
定义 信息 隐藏 类 的 外 部 视图 的 规约 ， 即 类 的 使 
用 者 需要 了 解 的 所 有 信息 。 

abstract operation ( 抽象 操作 ) 在 抽象 类 中 声 
明 并 且 未 实现 的 操作 。 

action ( 动作 ) 作为 状态 转移 的 结果 而 执行 的 运 
算 。 

active object ( 主动 对 象 ) 


见 concurrent object。 


Activity diagram ( 活动 图 ) 一 种 展示 活动 之 间 
控制 流 和 顺序 的 UML 图 。 
actor ( 参与 者 ) 与 系统 交互 的 外 部 用 户 或 相关 


的 用 户 集 合 (Rumbaugh,Booch,and Jacobson 
2005 )。 

aggregate class (RAZ) 在 聚合 关系 中 代表 
整体 的 类 (Booch, Rumbaugh, and Jacobson 
2005 )。 

aggregate subsystem ( REFRA) 较 低 层次 
的 子 系统 和 /或 对 象 的 逻辑 分 组 。 

aggregation ( RA) 一 种 较 弱 的 整体 /部 分 关 
系 的 形式 。 比 较 composition。 

algorithm object ( 算法 对 象 ) 封装 了 问题 域 中 
所 使 用 的 某 种 算法 的 对 象 。 

alternative feature ( 可 替换 特征 ) 可 以 被 选取 
并 用 来 替换 同一 软件 产品 线 中 其 他 特征 的 特 
дЕ. № common feature 和 optional feature, 

alternative use case ( 可 蔡 换 用 例 ) 可 以 被 选 
取 并 用 来 替换 同一 软件 产品 线 中 其 他 用 例 的 用 
例 。 比 较 kernel use case 和 optional use case. 

analog data ( 模拟 数据 ) 理论 上 具有 无 限 个 取 
值 的 连续 数据 。 

analysis modeling ( 分 析 建 模 ) COMET 基于 用 
例 的 软件 生存 周期 中 的 一 个 阶段 ， 在 此 期 间 进 


语 


表 


行 静态 建 模 和 动态 建 模 。 比 较 design modeling 
和 requirements modeling。 

application deployment ( 应 用 部 署 ) 确定 需要 
哪些 构件 的 实例 、 构 件 实 例如 何 互相 连接 以 及 
如 何 将 构件 实例 分 配 到 分 布 式 的 物理 结 点 上 的 
过 程 。 

application logic object ( 应 用 逻辑 对 象 ) 隐藏 
应 用 逻辑 细节 使 其 和 所 操作 的 数据 相 分 离 的 对 
象 。 

architectural pattern ( 体系 结构 模式 ) 
architectural pattern, 

association ( 关联 ) 两 个 或 多 个 类 之 间 的 关系 。 

asynchronous message communication ( 异步 
消息 通信 ) 通信 的 一 种 形式 ， 并 发 的 生产 者 
构件 (或 任务 ) 发 送 消息 给 并 发 的 消费 者 构件 
(或 任务 )， 并 且 不 等 待 响 应 ; 并 发 的 构件 (或 
任务 ) 之 间 可 能 需要 构建 一 个 消息 队列 。 也 称 
为 松 耦 合 消息 通信 。 比 较 synchronous message 
communication, 

at-least-one-of feature group ( 至 少 选 一 特征 组 ) 
从 中 选择 一 个 或 多 个 特征 的 特征 组 ， 但 必须 至 
少 选择 一 个 特征 。 


见 software 


B 


behavioral analysis ( 行为 分 析 ) 见 dynamic analysis. 

behavioral model ( 行为 模型 ) 描述 系统 对 从 外 
部 环境 接收 的 输入 所 做 出 的 响应 的 模型 。 

binary semaphore ( 二 元 信号 量 ) 用 于 实现 双 
向 互 斥 的 布尔 变量 。 也 简称 为 信号 量 。 

black box specification ( 黑 盒 规约 ) 描述 系统 
外 部 可 见 特 性 的 规约 。 

boundary object ( 边界 对 象 ) 通过 接口 与 外 部 
环境 相连 接 并 与 之 通信 的 软件 对 象 。 

broadcast communication ( 广播 通信 ) 一 种 群 
组 通信 的 形式 ， 消 息 会 以 主动 提供 的 方式 发 送 
给 所 有 的 接收 者 。 

broker( 代理 者 ) 客户 端 和 服务 之 间 交 互 的 中 介 。 
也 被 称 为 对 象 代 理 者 或 对 象 请 求 代理 者 。 

brokered communication ( 代理 者 通信 ) 在 分 布 
式 对 象 环境 中 客户 端 和 服务 通过 代理 者 进行 消 





息 通信 。 

business logic object ( 业务 逻辑 对 象 ) 为 处 理 
客户 端 请 求 而 封装 了 业务 规则 ( 特定 业务 的 应 
用 逻辑 ) 的 对 象 。 


C 


callback ( 回调 ) 由 客户 端 在 对 服务 的 异步 请 求 
中 发 送 的 一 种 操作 句柄 ， 并 且 服务 将 使 用 该 操 
作 句 柄 对 客户 端的 请 求 做 出 响应 。 

CASE JL Computer-Aided Software Engineering. 

category ( 类 别 ) 一 个 分 类 系统 中 专门 定义 的 一 
个 划分 。 

class (Ж) 一 种 对 象 类 型 ， 因 此 也 是 对 象 的 模 
板 。 是 抽象 数据 类 型 的 一 种 实现 方式 。 

class diagram ( 类 图 ) 通过 类 和 类 之 间 的 关系 来 
表示 系统 的 静态 视图 的 UML 图。 比较 interaction 
diagram。 

class interface specification ( 类 接口 规约 ) Е 
义 类 的 外 部 可 见 视图 的 规约 ， 包 括 该 类 所 提供 
操作 的 规约 。 

class structuring criteria ( 类 组 织 准则 ) М, object 
structuring criteria. 

client ( 客户 端 ) 客户 端 / 服 务 器 系统 中 的 服务 
的 请 求 者 。 比 较 server. 

client/server system ( 客户 端 / 服 务 器 系统 ) 由 
请 求 服务 的 客户 端 和 提供 服务 的 一 个 或 多 个 服 
务 器 构成 的 系统 。 

collaboration diagram ( 协作 图 ) 
UML1.x 中 的 名 称 。 

Collaborative Object Modeling and Architectural 
Design Method ( COMET， 协 作 式 对 象 建 模 和 
体系 结构 设计 方法 ) 覆盖 软件 开发 生存 周期 
中 的 需求 、 分 析 和 设计 建 模 阶段 的 一 种 迭代 的 
用 例 驱 动 和 面向 对 象 的 方法 。 

COMET 见 Collaborative Object Modeling and 
Architectural Design Method. 

commonality ( 共性 ) 在 软件 产品 线 的 所 有 成 员 
中 共有 的 功能 特性 。 比 较 variability。 

commonality/variability analysis ( 共性 /可 变性 
分 析 ) 通过 分 析 软 件 产品 线 中 的 功能 特性 以 
确定 哪些 功能 是 产品 线 所 有 成 员 所 共有 的 而 哪 
些 不 是 的 一 种 方法 。 

common feature ( 共性 特征 ) 软件 产品 线 中 每 
个 成 员 都 提供 的 特征 。 比 较 optional feature 和 
alternative feature。 

Common Object Request Broker Architecture 


通信 图 在 
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( CORBA， 公 共 对 象 请 求 代理 者 体系 结构 ) 由 
“对 象 管理 组 织 ”( Object Management Group ) 
制定 的 一 种 中 间 件 技术 的 开放 系统 标准 ， 用 于 
在 异 构 平 台 的 分 布 式 对 象 之 间 进 行 通信 。 

communication diagram ( 通信 图 ) UML 2 中 的 
一 种 交互 图 ， 用 于 描述 系统 中 对 象 通过 消息 进行 
交互 的 动态 视图 。 在 UML1.x 中 被 称 为 协作 图 。 

complex port ( 复杂 端口 ) 同时 支持 供给 接口 和 
请 求 接口 的 端口 。 

component ( 构件 ) 并 发 、 自 包含 且 拥 有 良 定义 
的 接口 的 一 种 对 象 ， 能 够 被 用 于 除 最 初 开 发 此 
构件 的 应 用 之 外 的 其 他 应 用 中 。 也 被 称 为 分 布 
式 构件 。 

component-based software architecture ( 基于 构 
件 的 软件 体系 结构 ) 一 种 提供 相应 的 基础 设施 
以 使 得 现 有 的 构件 可 以 被 复 用 的 软件 体系 结构 。 

component-based system ( 基于 构件 的 系统 ) 
一 种 提供 相应 的 基础 设施 以 使 得 现 有 的 构件 可 
以 被 复 用 的 系统 。 

component structuring criteria ( 构件 组 织 准 则 ) 
辅助 设计 者 将 系统 分 解 并 组 织 为 一 组 构件 的 一 
系列 启发 式 规则 。 

composite component ( 复合 构件 ) 包含 内 内 
子 构件 的 构件 ， 也 被 称 为 复合 子 系统 。 比 较 
simple component。 

composite object ( 复合 对 象 ) 包含 内 内 对 象 的 

composite state ( 复合 状态 ) 在 状态 图 中 被 分 解 
为 两 个 或 多 个 子 状 态 的 状态 。 也 被 称 为 超 状 态 。 

composite structure diagram ( 复合 结构 图 ) 
UML 2 中 的 图 ， 用 于 描述 复合 类 的 结构 和 之 间 
的 相互 关联 ; 常用 来 描述 构件 、 端 口 和 连接 器 。 

composite subsystem ( 复合 子 系统 ) М, composite 
component。 

composition ( 组 合 ) 一 种 比 聚 合 更 强 的 整体 / 
部 分 关系 形式 ; 部 分 对 象 和 复合 对 象 ( 整体 ) 
一 同 创 建 、 存 在 和 销毁 。 

Computer-Aided Software Engineering ( CASE， 
计算 机 辅助 软件 工程 ) 支持 软件 工程 方法 和 
表示 法 的 软件 工具 。 

concrete class ( 具体 类 ) 能 够 被 直接 实例 化 的 
类 (Booch, Rumbaugh, and Jacobson 2005 )。 
比较 abstract class. 

concurrent ( 并 发 ) 一 种 问题 、 过 程 、 系 统 或 应 
用 ， 其 中 多 个 活动 可 以 并 行 发 生 并 且 事 件 的 到 
达 顺 序 通常 是 不 可 预测 的 并 可 能 重 至 。 一 个 并 


404 Ж Ë KÅ 





发 系统 或 应 用 有 多 个 控制 线程 。 比 较 sequential, 

concurrent collaboration diagram ( 并 发 协作 图 ) 
JL concurrent communication diagram. 

concurrent communication diagram ( 并 发 通信 
图 ) 一 种 通信 图 ， 是 一 种 通过 异步 和 同步 消 
息 通信 来 描述 并 发 对 象 以 及 对 象 之 间 交 互 的 网 
络 图 。 在 UML1.x 中 被 称 为 并 发 协作 图 。 

concurrent object ( 并 发 对 象 ) 拥有 自己 的 控制 
线程 的 自主 对 象 。 也 被 称 为 主动 对 象 、 进 程 、 
任务 、 线 程 、 并 发 进程 或 并 发 任务 。 

concurrent process ( 并 发 进程 ) 
object。 

concurrent service ( 并 发 服务 ) 能 并 行 服务 于 
多 个 客户 端 请 求 的 服务 。 比 较 sequential service。 

concurrent task ( 并 发 任务 ) 见 concurrent object. 

condition ( ЗЕ) 在 一 段 有 限 的 时 间 间 隔 内 值 为 
真 或 假 的 布尔 变量 值 。 

connector ( 连接 器 ) 封装 了 两 个 或 多 个 构件 之 
间 互 连 协议 的 对 象 。 

constraint ( 约束 ) 必须 为 真 的 条 件 或 限制 。 

control object ( 控制 对 象 ) 为 其 他 对 象 提供 总 体 
协调 的 对 象 。 

coordinator object ( 协调 者 对 象 ) 一 种 全 局 决策 
对 象 ， 决 定 一 组 对 象 的 总 体 顺序 并 且 与 状态 无 关 。 

CORBA Я, Common Object Request Broker 
Architecture. 

critical section ( 临界 区 ) 对 象 内 部 逻辑 中 互 斥 
的 区 域 。 


М, concurrent 


D 


data abstraction ( 数据 抽象 ) 一 种 通过 操作 集 
合 来 定义 数据 结构 或 数据 类 型 的 方法 ， 因 此 可 
以 用 来 分 离 和 隐藏 表示 细节 。 

data abstraction class ( 数据 抽象 类 ) 封装 了 
数据 结构 或 数据 类 型 的 类 ， 因 此 可 隐藏 表示 细 
节 ; 类 提供 的 操作 可 管理 隐藏 的 数据 。 

database wrapper class ( 数据 库 包 装 器 类 ) [а 
藏 如 何 访问 存储 在 数据 库 中 的 数据 的 类 。 

data replication ( 数据 复制 ) 在 分 布 式 应 用 中 在 
多 个 地 方 复制 数据 ， 以 加 速 对 数据 的 访问 。 

deadlock ( 死 锁 ) 两 个 或 多 个 并 发 对 象 都 无 限期 
地 挂 起 的 一 种 情形 ， 因 为 每 个 并 发 对 象 都 在 等 
待 其 他 并 发 对 象 释放 某 种 资源 。 

default feature ( 默认 特征 ) 在 同一 软件 产品 线 
的 可 替换 特征 组 中 如 果 没 有 其 他 特征 显 式 地 被 
选择 系统 会 自动 选择 的 特征 。 





delegation connector ( 委托 连接 器 ) 连接 复合 
构件 的 外 部 端口 和 部 分 构件 的 内 部 端口 的 连接 器 ， 
这 样 到 达 外 部 端口 的 消息 会 转发 到 内 部 端口 。 

demand driven task ( 按 需 驱动 的 任务 ) 由 来 自 
其 他 任务 的 消息 或 内 部 事件 按 需 激活 的 任务 。 

deployment diagram ( 部 署 图 ) 一 种 UML Kl, 
通过 物理 结 点 以 及 结 点 之 间 的 物理 连接 ( 例如 
网 络 连接 ) 来 显示 系统 的 物理 配置 。 

design concept ( 设计 思想 ) 可 应 用 到 系统 设计 
过 程 中 的 一 种 根本 性 的 思想 。 

design method ( 设计 方法 ) 一 种 创建 设计 的 
系统 化 的 方法 。 该 设计 方法 可 帮助 标识 设计 决 
策 、 使 用 顺序 和 使 用 准则 。 

design modeling ( 设计 建 模 ) COMET 基 于 
用 例 的 软件 生命 周期 中 的 一 个 阶段 ， 在 此 阶 
段 中 设计 系统 的 软件 体系 结构 。 比 较 analysis 
modeling 和 requirements modeling, ` 

design notation( 设计 表示 法 ) 描述 设计 的 图 形 、 
符号 或 文字 的 方式 。 

design pattern ( 设计 模式 ) 关于 所 要 解决 的 某 
种 重复 出 现 的 设计 间 题 、 问 题 的 解决 方案 以 及 
使 用 解决 方案 的 上 下 文 环境 的 一 种 描述 。 

design strategy ( 设计 策略 ) 开发 设计 的 整体 规 
划 和 指导 。 

device interface object ( 设备 接口 对 象 ) 一 种 
信息 隐藏 对 象 ， 隐 藏 了 输入 /输出 设备 的 特性 
并 向 用 户 提供 虚拟 的 设备 接口 。 

device ИО boundary object ( 设备 输入 /输出 边 
ARR ) 接收 来 自 硬件 输入 /输出 设备 的 输入 
或 者 向 硬件 输入 /输出 设备 输出 的 软件 对 象 。 

discrete data ( 离散 数据 ) 以 一 定 的 时 间 间 隔 到 
达 的 数据 。 

distributed ( 分 布 式 ) 本 质 上 是 并 发 的 系统 或 应 
用 ,并 且 在 包含 多 个 不 同 地 理 分 布 的 结 点 的 环 
境 中 运行 。 

distributed application ”分 布 式 应 用 在 分 布 式 
环境 中 执行 的 应 用 。 

distributed component ( 分 布 式 构件 ) Jil component. 

distributed kernel ( 分 布 式 内 核 ) 支持 分 布 式 应 
用 的 操作 系统 的 原子 性 内 核 。 

distributed processing environment ( 分 布 式 处 
理 环境 ) 通过 局 域 网 或 广域网 将 多 个 地 理 上 
分 布 的 结 点 相互 连接 起 来 的 一 种 系统 配置 。 

distributed service ( 分 布 式 服务 ) 功能 可 以 分 
布 在 多 个 服务 器 结 点 上 运行 的 服务 。 

domain analysis( 领域 分 析 ) 软件 产品 线 的 分 析 。 
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domain engineering ( 领域 工程 ) И, software 
product line engineering. 

domain modeling ( 领域 建 模 ) 对 软件 产品 线 的 
建 模 。 

domain-specific pattern ( 特定 领域 模式 ) 特定 
于 给 定 软件 产品 线 的 软件 模式 。 

domain-specific software architecture ( 
领域 软件 体系 结构 ) 
architecture。 

dynamic analysis ( 动态 分 析 ) 帮助 确定 用 例 中 
的 对 象 如 何 进行 交互 的 一 种 策略 。 也 被 称 为 行 
为 分 析 。 

dynamic model ( 动态 模型 ) 考虑 一 个 问题 或 系 
统 的 控制 和 顺序 的 视图 ， 可 通过 对 象 的 有 限 状 
态 机 或 通过 多 个 对 象 间 的 交互 顺序 来 完成 。 

dynamic modeling ( 动态 建 模 ) 开发 系统 的 动 
态 模型 的 过 程 。 


特 定 


见 software product line 


E 


EJB Jil Enterprise JavaBeans. 

encapsulation ( 封装 ) JL information hiding. 

EJB JavaBeans ( 企业 级 ) 一 种 基于 Java 的 构 
件 技术 。 

entity class ( 实体 类 ) 一 种 类 ， 很 多 时 候 都 是 可 
持久 化 的 ， 其 实例 是 封装 信息 的 对 象 。 

entity object ( 实体 对 象 ) 一 种 软件 对 象 ， 很 多 
时 候 都 是 可 持久 化 的 ， 用 来 封装 信息 。 

entry action ( 进入 动作 ) 进入 某 个 状态 时 执行 
的 动作 。 比 较 exit action。 

event ( 事件 ) (1) 并 发 处 理 中 用 于 同步 目的 的 
外 部 或 内 部 的 激励 ， 它 可 以 是 一 个 外 部 中 断 、 
计时 器 超时 、 内 部 信和 号 或 内 部 消息 。(2 ) Ж 
互 图 中 在 某 个 时 间 点 到 达 一 个 对 象 的 一 个 激 
励 。 (3) 在 状态 图 中 引起 状态 转移 的 一 个 激 
励 的 发 生 。 

event driven I/O device ( 事件 驱动 的 输入 /输出 
设备 ) 产生 一 些 输入 或 处 理 完 输 出 操作 之 后 
会 产生 中 断 的 输入 /输出 设备 。 

event driven task ( 事件 驱动 任务 ) 被 外 部 事件 
(例如 中 断 ) 激活 的 任务 。 

event sequencing logic ( 事件 顺序 逻辑 ) 对 任 
务 如何 响 应 每 个 消息 或 事件 输入 的 描述 ， 尤 其 
是 每 个 输入 所 导致 的 输出 。 

event synchronization ( 事件 同步 ) 通过 信号 来 
控制 并 发 对 象 的 激活 。 事 件 同步 有 三 种 可 能 的 
类 型 : 外 部 中 断 、 计 时 器 超时 和 来 自 其 他 并 发 


对 象 的 内 部 信号。 

event trace ( 事件 轨迹 ) 对 每 一 个 外 部 输入 和 发 
生 时 间 的 基于 时 间 序 列 的 描述 。 

exactly-one-of feature group ( 选 一 特征 组 ) 对 
一 个 给 定 产 品 线 成 员 只 能 从 中 选择 一 个 特征 的 
特征 组 。 也 被 称 为 有 且 仅 有 一 个 特征 组 。 

exit action ( 退出 动作 ) 在 退出 状态 时 执行 的 动 
作 。 比 较 entry action, 

Extensible Markup Language ( XML， 可 扩展 标 
记 语 言 ) 允许 不 同 的 系统 通过 数据 和 文本 的 
交换 进行 相互 交互 的 技术 。 

external class ( 外 部 类 ) 在 系统 外 部 并 且 属 于 
外 部 环境 的 一 部 分 的 类 。 

external event ( 外 部 事件 ) 来 自 外 部 对 象 的 事 
件 ， 特 别 是 来 自 外 部 输入 /输出 设备 的 中 断 。 
比较 internal event。 

explicit feature ( 显 式 特征 ) 在 软件 产品 线 的 特 
定 应 用 中 可 以 单独 被 选择 的 特征 。 比 较 implicit 


feature。 
F 


family of systems ( 系统 家 族 ) 
product line。 

feature ( 特征 ) 一 种 功能 性 需求 ; 可 复 用 的 产 
品 线 需求 或 特性 。 需 求 或 特性 由 一 个 或 多 个 软 
件 产品 线 成 员 提 供 。 

feature-based impact analysis ( 基于 特征 的 影响 
分 析 ) 在 软件 产品 线 中 评估 特征 影响 的 一 种 
方法 ， 通 常 通过 动态 建 模 进行 。 

feature/class dependency ( 特征 /类 依赖 ) = 
示 一 个 或 多 个 类 支持 软件 产品 线 的 一 个 特征 的 
关系 (例如 实现 该 特征 所 定义 的 功能 )。 

feature/class dependency analysis ( 特征 /类 依 
赖 分 析 ) 为 了 确定 特征 /类 依赖 而 对 特征 和 类 
进行 评估 的 一 种 方法 。 

feature group ( 特征 组 ) 一 组 特征 ， 其 中 包含 软 
件 产品 线 成 员 在 使 用 这 些 特征 时 的 特定 约束 。 

feature modeling ( 特征 建 模 ) 分 析 和 明确 软件 
产品 线 中 的 特征 和 特征 组 的 过 程 。 

finite state machine ( 有 限 状态 机 ) 包含 有 限 个 
状态 和 由 输入 事件 引起 的 状态 转移 的 概念 化 机 
器 。 通 过 状态 转移 图 、 状 态 图 或 状态 转移 表 来 
表示 有 限 状态 机 。 也 被 简称 为 状态 机 。 

formal method ( 形式 化 方法 ) 使 用 形式 化 规约 
语言 的 一 种 软件 工程 方法 ， 即 具有 数学 化 定义 
的 语法 和 语义 的 语言 。 


Jl. software 


406 Ж Ž É 





generalization/specialization ( 泛 化 / 特 化 ) 公 
共 属 性 和 操作 被 抽象 到 超 类 ( 泛 化 类 ) 之 中 并 
且 被 子 类 ( 特 化 类 ) 继承 的 一 种 关系 。 


idiom ( 惯用 法 ) 描述 特定 编程 语言 实现 方案 的 
低层 次 模式 。 

implicit feature ( 隐 式 特征 ) 不 允许 被 单独 选择 
的 特征 。 比 较 explicit feature. 

incremental software development ( 增 量 软 件 开 
发 ) М, iterative software development. 

information hiding ( 信息 隐藏 ) 在 对 象 中 封装 软 
件 设计 决策 的 概念 ， 这 样 对 象 接口 只 显示 用 户 
需要 知道 的 东西 。 也 被 称 为 封装 。 

information hiding class ( 信息 隐藏 类 ) 根据 信 
息 隐藏 概念 构造 出 的 类 。 该 类 隐藏 了 被 认为 很 
可 能 变化 的 设计 决策 。 

information hiding class specification ( 信息 隐藏 
类 规约 ) 信息 隐藏 类 的 外 部 视图 的 规约 ， 包 
括 其 操作 。 

information hiding object ( 信息 隐藏 对 象 ) 信息 
隐藏 类 的 实例 。 

inheritance ( 继承 ) 类 之 间 共 享 和 复 用 代码 的 一 
种 机 制 。 

input object ( 输入 对 象 ) 接收 来 自 外 部 输入 设 
备 的 输入 的 软件 设备 输入 /输出 边界 对 象 。 

input/output object ( 输入 / 输出 对 象 ) 从 外 部 输 
入 /输出 设备 那里 接收 输入 并 向 其 发 送 输出 的 
软件 设备 输入 /输出 边界 对 象 。 

integrated communication diagram ( 集成 通信 图 ) 
多 个 通信 图 的 一 种 合成 ， 描 述 了 各 个 通信 图 上 所 
有 的 对 象 及 其 之 间 的 交互 。 也 被 称 为 合并 协作 图 。 

interaction diagram ( 交互 图 ) 一 种 UML 图 ， 
通过 对 象 和 对 象 之 间 传 递 的 消息 序列 来 表示 系 
统 的 动态 视图 。 通 信 图 和 顺序 图 是 两 种 主要 的 
交互 图 类 型 。 比 较 class diagram。 

interface ( 接口 ) 刻画 了 一 个 类 、 服 务 或 构件 
外 部 可 见 的 操作 ， 同 时 隐藏 了 操作 的 内 部 结构 
(实现 )。 

internal event ( 内 部 事件 ) 两 个 并 发 对 象 之 间 
的 一 种 同步 方法 。 比 较 external event。 

IO task structuring criteria ( 输入 /输出 任务 组 
Qe) 属于 一 种 任务 组 织 准则 ， 用 于 确定 
设备 输入 /输出 对 象 如 何 映射 到 输入 /输出 任 


务 以 及 输入 /输出 任务 何 时 被 激活 的 问题 。 

iterative software development ( 迭代 软件 开发 ) 
一 种 按 阶段 进行 的 软件 增 量 开发 方法 。 也 被 称 
为 增 量 软件 开发 。 


J 


JavaBeans 基于 Java 的 构件 技术 。 
Jini 在 嵌 人 式 系统 和 基于 网 络 的 计算 应 用 中 使 用 
的 一 种 连接 计算 机 和 设备 的 连接 技术 。 


K 


kernel ( 内 核 ) 软件 产品 线 或 操作 系统 的 核心 
部 分 。 

kernel class ( 核心 类 ) 软件 产品 线 中 所 有 成 员 
都 需要 的 类 。 比 较 optional class 和 variant class。 

kernel component ( 核心 构件 ) 软件 产品 线 中 所 
有 成 员 都 需要 的 构件 。 比 较 optional component 
和 variant component。 

kernel first approach ( 核心 首选 方法 ) 一 种 动 
态 建 模 方法 ， 用 于 确定 实现 核心 用 例 的 对 象 以 
及 对 象 间 如 何 交互 。 

kernel object ( 核心 对 象 ) 软件 产品 线 中 所 有 
成 员 都 需要 的 对 象 ; 是 核心 类 的 实例 。 比 较 
optional object 和 variant object。 

kernel system ( 核心 系统 ) 由 核心 类 和 任意 所 
需 的 默认 类 组 成 的 软件 产品 线 的 最 小 成 员 集合 。 

kernel use case ( 核心 用 例 ) 软件 产品 线 中 所 
有 成 员 都 需要 的 用 例 。 比 较 optional use case 和 


alternative use case. 


L 


loosely coupled message communication ( #2 
息 通信 ) М, asynchronous message communication. 


M 


mathematical model ( 数学 模型 ) 系统 的 数学 化 
表示 方法 。 

message dictionary ( 消息 字典 ) 显示 在 交互 图 
中 的 所 有 聚合 消息 的 定义 集合 ， 其 中 交互 图 包 
含 一 些 单 体 消息 。 

message sequence description ( 消息 序列 描述 ) 
显示 在 通信 图 或 顺序 图 上 ， 从 源 对 象 到 目标 对 
象 发 送 消息 序列 的 概要 描述 。 它 描述 当 每 条 消 
息 到 达 目 标 对 象 时 发 生 的 事情 。 

middleware ( 中 间 件 ) 位 于 异 构 化 操作 系统 之 上 
且 为 分 布 式 应 用 的 运行 提供 统一 平台 的 软件 层 。 





monitor ( 监控 ) 封装 了 数据 和 互 斥 执行 的 操作 
的 数据 对 象 。 

multicast communication ( 组 播 通 信 ) 见 subscription/ 
notification. 

multiple readers and writers ( 51255) 允许 
多 个 读 取 者 并 发 访问 同一 共享 数据 存储 库 的 算 
法 ; 写 人 者 必须 通过 互 斥 的 方式 来 更 新 数据 存 
储 库 。 比 较 mutual exclusion, 

mutual exclusion ( 互 斥 ) 在 同一 时 间 只 允许 
一 个 并 发 对 象 访问 共享 数据 的 算法 。 可 通过 
二 元 信号 灯 或 使 用 监控 的 方法 来 实现 。 比 较 
multiple readers and writers. 

mutual exclusion feature group ( 互 斥 特 征 组 ) 
针对 给 定 的 软件 产品 线 成 员 ， 至 多 可 选择 一 个 
特征 的 特征 组 。 比 较 mutually inclusive feature. 

mutually inclusive feature ( 互 包 含 特征 ) 必须 
和 其 他 特征 一 起 使 用 的 特征 。 比 较 mutually 


exclusive feature group. 


N 


negotiation pattern ( 协商 模式 ) 用 于 多 主体 系 
统 中 不 同 的 主体 之 间 相 互 协商 从 而 共同 做 出 决 
定 的 通信 方法 。 

node ( 结 点 ) 分 布 式 环境 下 的 部 署 单元 ， 通 常 
包括 一 个 或 多 个 共享 内 存 的 处 理 器 。 


O 


object (HR) 包含 被 隐藏 的 数据 和 数据 上 的 操 
作 的 类 的 实例 。 

object-based design ( 基于 对 象 的 设计 ) 基于 信 
息 隐藏 思想 的 软件 设计 方法 。 

object broker ( 对 象 代理 者 ) JL broker. 

object-oriented analysis ( 面向 对 象 分 析 ) 强调 
识别 问题 领域 中 的 真实 世界 的 对 象 并 将 其 映射 
为 软件 对 象 的 分 析 方 法 。 

object-oriented design ( 面向 对 象 设计 ) 基于 对 
象 、 类 和 继承 概念 的 软件 设计 方法 。 

object request broker ( 对 象 请 求 代理 者 ) JL brokers 

object structuring criteria ( 对 象 组 织 准 则 ) 帮助 
设计 者 将 系统 分 解 并 组 织 为 对 象 的 一 系列 启发 
式 规 则 ， 也 称 为 类 组 织 准 则 。 

one-and-only-one-of feature group ( 有 且 仅 有 一 个 
特征 的 特征 组 ) 见 exactly-one-of feature group. 

operation ( 操作 ) 由 类 执行 的 某 种 功能 的 规约 。 
由 类 提供 的 访问 过 程 或 函数 。 

optional class ( 可 选 类 ) 软件 产品 线 的 部 分 成 员 
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所 需要 的 类 。 比 较 kernel class 和 variant class. 

optional component ( 可 选 构件 ) 软件 产品 
线 的 部 分 成 员 所 需要 的 构件 。 比 较 kernel 
component 和 variant component。 

optional feature ( 可 选 特征 ) 软件 产品 线 的 部 
分 成 员 所 需要 的 特征 。 比 较 common feature 和 
alternative feature。 

optional object ( 可 选 对 象 ) 软件 产品 线 的 部 
分 成 员 所 需要 的 对 象 ; 可 选 类 的 实例 。 比 较 
kernel object 和 variant object。 

optional use case ( 可 选用 例 ) 软件 产品 线 的 部 
分 成 员 所 需要 的 用 例 。 比 较 kernel use case 和 
alternative use case. 

output object ( 输出 对 象 ) 向 外 部 输出 设备 提供 
输出 的 软件 设备 输入 /输出 边界 对 象 。 


Р 


package (#) UML 模型 元 素 的 一 种 分 组 。 

parameterized feature ( 参数 化 特征 ) 定义 了 一 
个 软件 产品 线 参 数 且 参数 值 需 要 在 产品 线 成 员 
中 定义 的 特征 。 

part component ( 部 分 构件 ) 复合 构件 中 的 一 个 
构件 。 

passive I/O device ( 被 动 输入 /输出 设备 ) 在 完 
成 输入 或 输出 功能 时 不 会 产生 中 断 的 设备 。 来 
自 被 动 输入 设备 的 输入 需要 通过 轮 询 或 按 需 进 
行 读 取 。 

passive object 被 动 对 象 ) 没有 控制 线程 的 对 象 ; 
其 操作 直接 或 间接 地 被 并 发 对 象 调 用 的 对 象 。 

performance analysis ( 性 能 分 析 ) 一 种 软件 设 
计 的 定量 分 析 ， 概 念 上 在 特定 的 硬件 配置 上 执 
行 并 且 有 特定 的 外 部 任务 应 用 于 该 分 析 。 

performance model ( 性 能 模型 ) 现实 世界 计算 
机 系统 行为 的 一 种 抽象 ， 用 于 更 深入 地 了 解 系 
统 的 性 能 ， 不 论 该 系统 是 否 真实 存在 。 

periodic task ( 周期 性 任务 ) 被 计时 器 事件 周期 
性 激活 ( 例如 相同 的 时 间 间 隔 ) 的 并 发 对 象 。 

PLUS 见 Product Line UML-Based Software 
Engineeringo 

port ( 端口 ) 用 于 构件 之 间 通 信 的 连接 点 。 

prerequisite feature ( 前 提 特 征 ) 被 其 他 特征 依 
赖 的 特征 。 

primary actor( 主要 参与 者 ) 发 起 用 例 的 参与 者 。 
比较 secondary actor。 

priority message queue ( 优先 级 消息 队列 ) 每 
个 消息 都 有 相应 的 优先 级 的 消息 队列 。 消 费 者 总 
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是 在 低 优先 级 的 消息 之 前 接收 高 优先 级 的 消息 。 
process ( 进程 И, concurrent object. 

product family ( 7* да Ж ) № software product 
line. 

product line ( 产品 线 ) М, software product line, 

product line engineering (= БЕЛЕ) м 
software product line engineering. 

Product Line UML-Based Software Engineering, 
PLUS ( 基于 UML 的 软件 产品 线 工程 ) 针对 
软件 产品 线 的 一 种 设计 方法 ， 描 述 了 如 何 使 用 
UML 对 软件 产品 线 进行 需求 建 模 、 分 析 建 模 
和 设计 建 模 。 

provided interface ( 供给 接口 ) 刻画 了 一 个 构 
件 (或 类 ) 中 必须 实现 的 操作 。 比 较 required 
interface. 

provided port( 供给 端口 ) 支持 供给 接口 的 端口 。 


比较 required port。 
proxy object ( 代理 对 象 ) 与 外 部 系统 或 子 系统 
连接 并 进行 通信 的 软件 对 象 。 


pseudocode ( 伪 代 码 ) 用 于 描述 对 象 或 类 的 算 
法 细节 的 一 种 结构 化 英语 表达 形式 。 


Q 


queuing model ( 排队 模型 ) 一 种 计算 机 系统 的 
数学 表示 ， 用 于 分 析 对 有 限 资 源 的 竞争 。 


R 


Rational Unified Process (RUP, Rational 统一 过 
# ) J Unified Software Development Process 
(USDP )。 

real-time ( 实时 ) 是 指 这 样 一 种 问题 、 系 统 或 应 
用 ,其 自身 是 并 发 的 并 且 带 有 了 时间 约 来 ， 要 求 
到 达 的 事件 必须 在 一 个 给 定 的 时 间 段 内 处 理 。 

remote method invocation ( RMI， 远 程 方法 调 
Я) 人 允许 分 布 式 的 Java 对 象 相互 通信 的 中 间 
件 技术 。 

required interface ( 请 求 接口 ) 由 其 他 构件 (或 
类 ) 提供 的 、 供 特定 的 构件 ( 或 类 ) 在 特定 环 
境 下 执行 的 操作 。 比 较 provided interface. 

required рогі ( 请 求 端口 ) 支持 请 求 接口 的 端口 。 
比较 provided port。 

requirements modeling ( 需求 建 模 ) COMET 基 
于 用 例 的 软件 生命 周期 中 的 一 个 阶段 ， 其 中 系 
统 的 功能 性 需求 通过 用 例 模 型 的 开发 来 确定 。 





比较 analysis modeling 和 design modeling。 

reuse category ( 复 用 类 型 ) 软件 产品 线 中 的 建 
模 元 素 ( 用 例 、 特 征 、 类 等 ) 依据 各 自 的 复 用 
属性 ( 例如 核心 或 可 选 ) 所 进行 的 分 类 。 比 较 
role category. 

reuse stereotype ( 复 用 构造 型 ) 表示 建 模 元 素 
的 复 用 分 类 的 UML 表示 法 。 

ВМ! И, remote method invocations 

role category ( 角色 类 型 ) 应 用 中 的 建 模 元 
素 ( 类 、 对 象 、 构 件 ) 依据 各 自 充 当 的 角色 
(例如 控制 或 实体 ) 进行 的 分 类 。 比 较 reuse 
category. 

role stereotype ( 角色 构造 型 ) 表示 建 模 元 素 的 
角色 分 类 的 UML 表示 法 。 

КУР И Rational Unified Process. 


$ 


scenario (Жж) 用 例 或 对 象 交 互 图 中 的 一 个 特 
定 的 路 径 。 

secondary actor ( 次 要 参与 者 ) 参与 (但 没有 
发 起 ) 用 例 的 参与 者 。 比 较 primary actor. 

semaphore ( 信号 量 ) 见 binary semaphore. 

sequence diagram ( 顺序 图 ) 一 种 UML 的 交互 
图 ， 它 描述 系统 的 动态 视图 ， 其 中 参与 交互 的 
对 象 水 平 表 示 ， 时 间 垂 直 表 示 ， 消 息 的 交互 从 
顶部 到 底部 按 顺序 表示 。 

sequential ( 顺序 性 ) 指 问题 、 进 程 、 系 统 或 应 
用 中 的 活动 都 严格 按照 顺序 发 生 ; 顺序 性 的 系 
统 或 应 用 只 有 一 个 控制 线程 。 比 较 concurrent。 

sequential service ( 顺序 性 服务 ) 一 个 服务 完 
成 客户 端的 请 求 后 再 开始 下 一 个 服务 。 比 较 
concurrent service. 

server ( 服务 器 ) 提供 一 个 或 多 个 服务 的 系统 
结 点 。 

service ( 服务 ) 在 SOA 中 分 布 式 、 自 治 、 异 构 、 
PAB. TERA 2 AE AE ~ 

service object ( 服务 对 象 ) 为 其 他 对 象 提 供 服 
务 的 软件 对 象 。 

service-oriented architecture ( SOA， 面 向 服务 
的 体系 结构 ) НА НИ. ЯМ, ЖЖ 
合 、 可 发 现 和 可 复 用 的 服务 组 合 而 成 的 软件 体 
系 结构 。 

simple component ( 简单 构件 ) 不 包含 其 他 构 
件 的 构件 。 比 较 composite component. 

simulation model ( 模拟 模型 ) 系统 的 一 种 算法 
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表示 ， 反 映 了 系统 在 一 段 时 间 之 内 动态 变化 的 
结构 和 行为 ， 因 此 提供 了 一 种 分 析 系 统 在 一 段 
时 间 之 内 动态 行为 的 方法 。 

SOA И, service-oriented architecture, 

software application engineering ( 软件 应 用 工程 ) 
软件 产品 线 工 程 中 的 一 个 过 程 ， 在 此 过 程 中 通 
过 配置 并 修改 软件 产品 线 体 系 结构 来 开发 一 个 
属于 软件 产品 线 成 员 的 软件 应 用 。 也 被 称 为 应 
用 工程 。 

software architectural pattern ( 软件 体系 结构 模 
R) 在 一 系列 软件 应 用 中 反复 使 用 的 体系 结 
构 。 也 被 简称 为 体系 结构 模式 。 

software architectural communication pattern ( 软 
件 体 系 结构 通信 模式 ) 针对 软件 体系 结构 中 分 
布 式 构件 之 间 的 动态 通信 的 软件 体系 结构 模式 。 

software architectural structure pattern ( 软件 体 
系 结构 结构 模式 ) 针对 软件 体系 结构 中 的 静 
态 结构 的 软件 体系 结构 模式 。 

software architecture ( 软件 体系 结构 ) 通过 构 
件 以 及 构件 间 的 关系 来 描述 系统 整体 结构 的 一 
种 高 层 设 计 ， 与 各 个 构件 的 内 部 细节 相 分 离 。 

software product family ( 软件 产品 族 ) М, software。 

software product family engineering ( 软件 产品 
族 工 程 ) И, software product line engineering. 

software product line ( 软件 产品 线 ) 拥有 一 些 
共性 功能 和 一 些 可 变性 功能 的 软件 系统 家 族 ; 
共享 一 组 公 性 且 受 管理 的 特征 、 满 足 某 个 细 分 
市 场 或 任务 的 特定 需求 、 并 且 在 一 组 通用 的 核 
心 资 产 基 础 上 按照 事先 定义 的 方式 开发 出 来 的 
一 系列 软件 密集 型 系统 ( Clements and Northrop 
2002 )。 也 被 称 为 系统 家 族 、 软 件 产品 族 、 产 
品 族 或 产品 线 。 

software product line architecture ( 软件 产品 线 体 
系 结构 ) 一 个 产品 族 的 体系 结构 ， 描 述 了 软件 
产品 线 中 的 核心 、 可 选 和 可 变性 构件 及 其 之 间 的 
互 连 。 也 被 称 为 “特定 领域 的 软件 体系 结构 "”。 

software product line engineering ( 软件 产品 线 
LE) 指 软件 产品 线 的 设计 和 开发 过 程 ， 其 
中 包括 分 析 软 件 产品 线 的 共性 和 可 变性 ， 并 且 
开发 产品 线 的 用 例 模 型 、 分 析 模 型 、 软 件 产品 
线 体系 结构 和 复 用 构件 。 也 被 称 为 软件 产品 族 
工程 、 产 品 族 工程 或 产品 线 工程 。 

software system context class diagram ( 软件 系 
统 上 下 文 类 图 ) 一 种 描述 软件 系统 ( 表示 为 
聚合 类 ) 和 软件 系统 之 外 的 外 部 类 之 间 关 系 的 
类 图 。 比 较 system context class diagram。 


software system context model ( 软件 系统 上 下 
文 模型 ) 在 软件 系统 上 下 文 类 图 中 描述 的 软 
件 系统 边界 模型 。 比 较 system context model。 

spiral model ( 螺旋 模型 ) 一 种 风险 驱动 的 软件 
过 程 模型 。 

state ( 状态 ) 一 种 在 一 段 时 间 间 隔 内 存在 的 可 
识别 的 情形 。 

statechart ( 状态 图 ) 一 种 层次 化 状态 转移 图 ， 
其 中 结 点 表示 状态 ， 弧 表示 状态 转移 。 

Statechart diagram ( UML 状态 图 ) UML 1.x 中 
状态 机 图 的 名 称 。 

state-dependent control object ( 状态 相关 的 控 
制 对 象 ) 隐藏 有 限 状态 机 细节 的 对 和 象 ; 即 该 
对 象 封 装 了 状态 图 、 状 态 转 移 图 或 状态 转移 表 
的 内 容 。 

state machine ( 状态 机 ) 见 finite state machine. 


state machine diagram ( 状态 机 图 ) 有 限 状 态 
机 或 状态 图 的 UML 描述 。 
state transition ( 状态 转移 ) 由 输入 事件 引起 的 


state transition diagram ( 状态 转移 图 ) 有 限 状 
态 机 的 图 形 化 表示 ， 其 中 结 点 表示 状态 ， 弧 表 

state transition table ( 状态 转移 表 ) 
机 的 表格 式 表 示 。 

static modeling ( 静态 建 模 ) 为 一 个 问题 、 系 统 
或 软件 产品 线 开 发 静态 、 结 构 化 视图 的 过 程 。 

stereotype ( 构造 型 ) 基于 现 有 的 UML 建 模 元 
素 并 根据 建 模 者 的 问题 进行 裁剪 得 到 的 用 于 定 
义 新 的 构造 块 的 一 种 分 类 ( Booch, Rumbaugh, 
and Jacobson 2005 )。 

subscription/notification ( 订阅 /通知 ) 一 种 群 
组 通信 方式 ， 其 中 订阅 者 接收 事件 通知 。 又 称 
为 组 播 通信 。 

substate( 子 状态 ) 属于 复合 状态 一 部 分 的 状态 。 

subsystem( FAS) 整个 系统 的 重要 组 成 部 分 ; 
子 系统 提供 整个 系统 的 一 个 功能 子 集 。 

subsystem communication diagram ( 子 系 统 通 
Е) 描述 子 系统 及 其 之 间 交 互 的 高 层 通信 图 。 

superstate ( 超 状态 ) 一 个 复合 状态 。 

synchronous message communication ( 同步 消 
息 通信 ) 一 种 通信 方式 ， 其 中 生产 者 构件 (或 
并 发 任务 ) 发 送 消息 到 消费 者 构件 (或 并 发 任 
务 ) 并 立即 等 竺 确认 。 也 被 称 为 紧 辜 合 消息 通 
信 。 比 较 asynchronous message communication。 

synchronous message communication with 


有 限 状 态 
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reply ( 带 回复 的 同步 消息 通信 ) 一 种 通信 方 
式 ， 其 中 客户 端 构 件 (或 生产 者 任务 ) 发 送 消 
息 到 服务 构件 ( 或 消费 者 任务 ) 并 等 待 回复 。 
也 被 称 为 带 回复 的 紧 辜 合 消息 通信 。 
synchronous message communication without 
геру ( 不 带 回复 的 同步 消息 通信 ) 一 种 通信 
方式 ， 其 中 生产 者 构件 ( 或 任务 ) 发 送 消息 到 
消费 者 构件 (或 任务 ) 并 等 待 消 费 者 接收 消 
息 。 也 被 称 为 不 带 回复 的 紧 耦 合 消息 通信 。 
system context class diagram( 系统 上 下 文 类 图 ) 
描述 系统 ( 表示 为 聚合 类 ) 和 系统 外 部 的 外 
部 类 之 间 关 系 的 类 图 。 比 较 software system 
context class diagram. 
system context model ( 系统 上 下 文 模型 ) 在 系 
统 上 下 文 类 图 中 描述 的 系统 ( 硬件 和 软件 ) 边 
界 模型 。 比 较 software system context model。 
system interface object ( 系统 接口 对 象 ) 隐藏 
对 于 外 部 系统 或 子 系统 的 接口 的 对 象 。 
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task ( 任务 ) JL concurrent object. 

task architecture ( 任务 体系 结构 ) 通过 其 
接口 和 互 连 对 系统 或 子 系统 中 的 并 发 对 象 的 

thread ( 线程 ) 见 concurrent object。 

tightly coupled message communication ( 紧 耦 合 消 
息 通信 ) М, synchronous message communication. 

tightly coupled message communication 
with reply ( 带 回 复 的 紧 耦 合 消息 通信 ) и, 
Synchronous message communication with reply。 

tightly coupled message communication without 
reply ( 不 带 回 复 的 紧 耦 合 消息 通信 ) и, 
synchronous message communication without 
reply. 

timer event ( 计时 器 事件 ) 用 来 周期 性 激活 并 发 
对 象 的 一 种 激励 。 

timer object ( 定时 器 对 象 】 被 外 部 计时 器 激活 
的 控制 对 象 。 

timing diagram ( 时 间 图 ) 显示 一 组 并 发 对 象 按 
照 时 间 顺 序 执 行 的 图 。 

transaction ( 事务 ) 来自 客户 端的 服务 请 求 ， 所 
请 求 的 服务 包括 两 个 或 多 个 操作 并 且 这 些 操作 
要 么 全 部 完成 要 么 全 部 都 未 执行 。 

two-phase commit protocol ( 两 阶段 提交 协议 ) 
分 布 式 应 用 中 用 来 同步 更 新 的 一 种 算法 ， 目 的 
是 确保 原子 性 的 事务 要 么 提交 要 么 终止 。 
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UML М, Unified Modeling Language, 

Unified Modeling Language ( UML， 统 一 建 模 语 
Е) 用 于 可 视 化 、 规 约 、 构 造 和 文档 化 软件 
密集 型 系统 中 的 制品 的 一 种 语言 。 

Unified Software Development Process ( USDP, 
统一 软件 开发 过 程 ) 一 种 使 用 UML 表示 
法 的 迭代 式 用 例 驱 动 的 软件 过 程 。 也 被 称 为 
Rational 统一 过 程 (КИР), 

USDP Jil Unified Software Development Processo 

use case ( 用 例 ) 对 一 个 或 多 个 参与 者 与 系统 之 
间 的 一 系列 交互 所 进行 的 描述 。 

use case diagram ( 用 例 图 ) 显示 一 组 用 例 、 
参与 者 及 它们 之 间 关 系 的 UML 图 (Booch, 
Rumbaugh, and Jacobson 2005 )。 

use case model ( 用 例 模型 ) 基于 参与 者 和 用 
例 的 系统 功能 性 需求 的 描述 。 

use case modeling ( НЯ) 开发 一 个 系统 
或 软件 产品 线 的 用 例 的 过 程 。 

use case package ( 用 例 包 ) 一 组 相关 的 用 例 。 

user interaction object ( 用 户 交互 对 象 ) 与 个 人 
用 户 进行 交互 的 软件 对 象 。 


V 


variability ( 可 变性 ) 软件 产品 线 的 部 分 成 
员 ( 但 不 是 全 部 成 员 ) 所 提供 的 功能 。 比 较 
commonality。 

variant class ( 变 体 类 ) 与 另 一 个 类 相似 但 不 相 
同 的 类 ;与 同一 个 父 类 的 其 他 子 类 相似 但 不 相 
同 的 子 类 。 比 较 kernel class 和 optional class。 

variant component ( 变 体 构件 ) 与 另 一 个 构件 
相似 但 不 相同 的 构件 。 比 较 kernel component 
和 optional component。 

variant object ( 变 体 对 象 】 与 男 一 个 对 象 相似 但 
不 相同 的 对 象 ; 是 变 体 类 的 实例 。 比 较 kernel 
object 和 optional object. 

variation point( 可 变 点 ) 在 软件 产品 线 制品 ( 例 
如 用 例 或 类 ) 中 会 发 生 改 变 的 位 置 。 

visibility ( 可 见 性 ) 定义 了 类 中 的 元 素 是 否 对 外 
部 类 可 见 的 一 种 特性 。 
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Web service (Web 服务 ) 由 服务 提供 者 通过 互 
联网 提供 给 万 维 网 用 户 的 一 种 业务 功能 。 
white page brokering ( AARE) 客户 端 和 代 


理 者 之 间 的 一 种 通信 模式 ， 其 中 客户 端 知 道 所 
需要 的 服务 但 是 不 知道 位 置 。 比 较 yellow page 
brokering。 
whole/part relationship ( 整体 / 部 分 关系 ) 组 合 
或 聚合 关系 ， 其 中 整体 类 由 多 个 部 分 类 组 成 。 
wrapper component ( 包装 器 构件 ) 处 理 客户 
端 对 遗留 应 用 请 求 的 通信 和 管理 的 分 布 式 构件 
( Mowbray and Ruh 1997 )。 
х 


XML № Extensible Markup Language. 
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yellow page brokering ( HARE) 客户 端 和 代 
理 者 之 间 的 一 种 通信 模式 ， 其 中 客户 端 知道 所 
需要 的 服务 类 型 但 是 不 知道 具体 的 服务 。 比 较 


white page brokering. 
2 


zero-or-more-of feature group ( 零 到 多 个 特征 的 
特征 组 ) 包含 可 选 特征 的 特征 组 。 

zero-or-one-of feature group ( 零 到 一 个 特征 的 特征 
组 ) 所 包含 的 所 有 特征 两 两 互 斥 的 特征 组 。 
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